🚀 go-pugleaf

> It always pulls all table records over to the client and does filtering 
> there.

TADOTable does not pull all records when used with CursorLocation = 
clUseServer. It may pull record handles, but not record data. Although using 
TADODataSet/TADOQuery is preferred for most DBMS, sometimes using TADOTable 
is justified.

//------------------------------------------
Regards,
Vassiliev V. V.
http://www.managed-vcl.com - using .Net objects in Delphi for Win32 + 
ADO.Net
http://www.oledbdirect.com - The fastest way to access MS SQL Server,
MS Jet (Access) and Interbase (through OLEDB)

"Arnie" <none> �������/�������� � �������� ���������: 
news:43036726@newsgroups.borland.com...
> "Foo Tze Wan" <twfoo@nospam.com> wrote in message 
> news:4302e629@newsgroups.borland.com...
>> Hi all,
>>
> ... snip ...
>> 1) This is the most important question I would like to know:
>>
>> I would like to avoid the BDE. Using the TDatabase and TTables components 
>> as
>> of now, are they equivalent to saying that BDE is also implicitly being
>> used? The BCB help file mention the following for the TTable 
>> description -
>> "Use TTable to access data in a single database table using the Borland
>> Database Engine (BDE)".
>> Does it mean by using  TTables or even TDatabase, I would also need to
>> incorporate the BDE when the project is ready for deployment?
>
> Yes, TDatabase and friends are based on the BDE.  I would STRONGLY 
> recommend that you stay away from the BDE.  I would also recommend that 
> you stay away from xxxTable component.  It was originally used for file 
> based DBs such as DBase and should not be used with current DB servers. 
> It always pulls all table records over to the client and does filtering 
> there.  Using a WHERE clause in a SELECT statement allows the DB server to 
> do the filtering.  A TADOQuery or TADODataset is the way to go here. The 
> TADOQuery is fairly close to compatible to a TQuery.
>
>>
>> 2) The second question is: My application would still like to retain the
>> ODBC features in order to support databases that are ODBC-compliant. I 
>> think
>> I read in one of the postings that it may still be possible to use ODBC 
>> over
>> ADO (not sure if this is the correct term to use). I have not explored 
>> the
>> ADO components yet, but will try to do so. In the meantime, can I know if 
>> it
>> is advisable to use this concept of "ODBC over ADO" for my requirement?
>
> It's more like "ADO over ODBC", and yes, you can do it, though most will 
> recommend against it.  MS provides an OLEDB driver for "generic ODBC".  It 
> can be used with Borland's ADO.  You'd probably be better off using the 
> OLEDB provider supplied by the manufacturer if you support other DBs.
>
> If you go with ADO, you'll have to do sime fiddling with the query or 
> dataset properties in order to get good performance. These include cursor 
> location and type as well as locking mode and cache size.
>
>> Thanks in advance,
>> Tze Wan
>
> HTH,
> - Arnie
>