Re: TADO vs. TQuery

"Maurice Telkamp" <maurice.telkamp_at_beeone.nl> wrote in message
news:42b7c5c9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> "Allan Nielsen" <ace-allanREMOVEME@xxxxxxxxxxxxxx> wrote in
> message news:42b7ab33@xxxxxxxxxxxxxxxxxxxxxxxxx
>> How much faster is ADO typically over a simple TQuery using
>> odbc?
>> I have an application that uses ODBC to connect to MS SQL
>> Server 2K. Will
>> this benefit greatly if I changed to ADO?
>>
>> Thank you.
>>
>> Allan
>>
>
> I guess most of the guys here will claim that BDE is pretty
> fast, but I have no complaints about ADO. But I would not
> consider speed the dealbreaker here. Go for ADO, you will not
> regret it. Ease of use, ease of configuration, capabilities
> etc. Besides that, using ADO, you can still use ODBC (allthough
> I would not recommend that)
>
> Maurice
>

It will take a while to 'tune up' ADO objects to get BDE speed.
But if you're leaving BDE (highly recommended) it's worth the
effort. And for God's sake, don't use Table objects.

Also, don't knock ODBC.

Here's a little story. We used BDE several years ago. We were
using an Oracle DB. Eventually we started using DOA (Direct
Oracle Access) for the heavy duty console apps. DOA is written
using Oracle's OCI and was much faster than BDE. Then we had to
support DB2 and eventually SQL Server. I wrote two sets of
database objects. One (RMS) that provided the same interface as
BDE but used TADO under the covers. The other (GDB) provided the
same API as DOA. It used either the DOA DLL for Oracle or the
RMS DLL for DB2 and SQL Server. Either was dynamically loaded
depending upon which DB was in use. DOA was still MUCH faster
than using ADO. Life was good - well, OK anyway.

Recently 'we' decided to port those heavy duty console apps to
VC++. In the end, I ripped the guts (ADO) out of the RMS DB
objects and replaced them with ODBC. I also got rid of the
GDB/DOA objects. One reason for this is that we're going to 64
bit real soon and DOA is based on the VCL (TDataset). So, now I
had the RMS DB objects, providing a BDE-like API, using ODBC.
This made for a pretty easy port. Porting away from the GDB/DOA
objects took more work but was largely mechanical. Note that we
have around 140 of these console apps. Most used a combination
of the RMS and GDB objects.

So, on to the bottom line. We have the first couple of apps
(using ODBC) working. DOA showed about a 8X speed improvement
over ADO. The BIG one, using ODBC, one shows a speed improvement
of about 25% over DOA. Overall, ODBC, archaic as it is, is
pretty danged fast compared to COM. The API was modified for
reading and writing BLOBs so that it's easier to use (vs
TBlobStream or whatever) and requires fewer lines of code. Also,
the BIG app can now easily use > 2GB of memory when the /3GB
switch is turned on. Previously, it could not (VCL/DOA?).

The whole project was a fairly large undertaking. However, we
can now use any DB, selected at runtime, with performance far
exceeding ADO. Note however that none of these objects connect
to data-aware controls.

Some background. We deal with point of sale retail grocer (and
other) data where the DB size regularly exceeds a terabyte. The
data consists of every transaction at every store and includes
all detail records for each transaction (items, coupons, tenders,
etc). Keep all that for two years ...

- Arnie



.

Relevant Pages