Re: Data Report help - VB6


"Jim Carlock" <anonymous@localhost> wrote in message
news:uDZYY8t$GHA.4292@xxxxxxxxxxxxxxxxxxxxxxx
"JP Bless" <jp3BlessNoSpam@xxxxxxxxxxx> wrote:
: As you will discover soon; DataReport was designed by a bunched of
: aliens out on a "moon" mission ...

DataReport is pretty cool, but that's all I'll say about that. Not sure
how far along the OP is, nor his familiarity with Microsoft Access .mdbs,
but Access represents an alternative as well. Using DAO to access the
Access queries works great. It might sound a little wacked, but if the
data
only has one user accessing the data, Access tends to make things quite
easy. If messing with less than 1,000,000 records Access makes sense in
those cases as well. DAO plays a bigger role and is better than ADO when
the number of records in a recordset passes 100,000. My numbers are
guesses, but Access really is helpful in those cases. On the other hand,
Access works well enough with up to maybe 100,000 records at a time
through ADO.

You can distribute Access .mdbs with your application to hold your
data, and the Queries button makes things really easy to design queries.
DAO represents the native methods for getting access to Access data
sources and is substantially faster than ADO, but then the VB controls
sometimes create problems.

Anyways, that represents a possible valid option for the OP as well.

--
Jim Carlock
Post replies to the group.

Hi Jim,

I am pretty familiar with M$Access. This app was originally written in
M$Access VBA, but I had people that needed access to the data that didn't
have M$Access, so I'm busy porting it over to VB6. I've pretty much got the
app working, and the reports are my last hurdle.

I don't think looking up queries in the .mdb would work because my app
builds the SQL statement for the recordset on the fly, not based on fixed
queries. The user has a bunch of check boxes they can choose, along with
some date range fields and based on what is and is not selected, the SQL
statement gets created.

I'm using ADO, and I think this should be OK, because it would be a long
time before I get past 100,000 records. The data is on my company's stores,
and we have 950'ish right now, growing 50 to 100 per year at our current
rate.

But thanks for the suggestions!

Darhl


.

Loading