🚀 go-pugleaf

"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 

Thanks, Arnie for your reply.

>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.

The reason why I thought my application should retain ODBC connectivity to 
databases is because these databases are ODBC compliant only, but not OLEDB. 
(Perhaps, I have not been in tune with newer data access technologies.) The 
databases we envision we will be using are Oracle and SQLServer. After some 
brief searces on the web, I think they should also support OLEDB.

>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.

I will try with ADO, and when these issues arise, will grapple with them. I 
hope help from here and the web can be easily found then.

Thanks again,
Tze Wan

Oracle has its own OLEDB provider and another OLEDB provider is included in 
MDAC (Microsoft Data Access Components, setup for OLEDB/ADO). The first one 
should be distributed with your application, second is installed yet on most 
computers or can be installed with MDAC. MS SQL Server is one of DBMS ADO 
was developed for, OLEDB provider for it is included in MDAC.

//------------------------------------------
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)

"Foo Tze Wan" <twfoo@nospam.com> �������/�������� � �������� ���������: 
news:4303e931@newsgroups.borland.com...
> Thanks, Arnie for your reply.
>
>>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.
>
> The reason why I thought my application should retain ODBC connectivity to
> databases is because these databases are ODBC compliant only, but not 
> OLEDB.
> (Perhaps, I have not been in tune with newer data access technologies.) 
> The
> databases we envision we will be using are Oracle and SQLServer. After 
> some
> brief searces on the web, I think they should also support OLEDB.
>
>>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.
>
> I will try with ADO, and when these issues arise, will grapple with them. 
> I
> hope help from here and the web can be easily found then.
>
> Thanks again,
> Tze Wan
>
> 

> 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
>