Board index » delphi » BDE vs ADO

BDE vs ADO

I'm working with Delphi 7 Pro on a large SQL Server shipping database.
 When trying to set up master/detail relationships using ADO
components, I get system memory errors and my machine locks up.  I've
maxed my virtual memory page size, and that didn't help.

I set up a four level relationship
(Manifest->Shipment->Container->Contents) with BDE components, and it
works fine.  But when I try to duplicate this structure with ADO
components, I can't set the MasterFields attribute without crashing
Delphi.

I assume that BDE is creating indices and caching portions of the
dataset, querying when necessary.  ADO seems to be trying to download
all the data from all the associated tables into memory.

Are there settings for the ADO components that will solve this
problem?

Bill Reynolds

 

Re:BDE vs ADO


On 18 Jun 2003 15:47:32 -0700, TruckeeB...@ltol.com (Bill Reynolds)
wrote:

Quote
>I'm working with Delphi 7 Pro on a large SQL Server shipping database.
> When trying to set up master/detail relationships using ADO
>components, I get system memory errors and my machine locks up.  I've
>maxed my virtual memory page size, and that didn't help.

>I set up a four level relationship
>(Manifest->Shipment->Container->Contents) with BDE components, and it
>works fine.  But when I try to duplicate this structure with ADO
>components, I can't set the MasterFields attribute without crashing
>Delphi.

>I assume that BDE is creating indices and caching portions of the
>dataset, querying when necessary.  ADO seems to be trying to download
>all the data from all the associated tables into memory.

>Are there settings for the ADO components that will solve this
>problem?

>Bill Reynolds

I support your question Bill

I have experienced the same problem when I am trying to access a table
of almost one mill. records. (on Microsoft SQL Server) . The program
is taking forever to load.  So long that I don't know how long,
because i can't wait.
If anyone have the answer, there are two of us that wonder about this
problem

Regards Roger

Re:BDE vs ADO


Quote
Roger Valand wrote:
> ...
> I have experienced the same problem when I am trying to access a table
> of almost one mill. records. (on Microsoft SQL Server) . The program
> is taking forever to load.  So long that I don't know how long,
> because i can't wait.
> If anyone have the answer, there are two of us that wonder about this
> problem

> Regards Roger

The problem is often that you are using "Table" components with a
Client/Server database.  TTables are for desktop databases (Access,
Paradox), or small tables (with C/S databases).  You are probably opening
one or more (largish) tables early on in the program.
The solution is to use "Queries" (almost) exclusively.  Don't fetch more
records (or fields) than the user needs - and he should be prepared to
provide reasonable criteria for selecting a (small) subset of the records
in the tables.
Don't make 'browsing' type apps showing thousands of records in a grid
(which one may tend to do with a desktop database).  Remember to define
appropriate indexes for selecting records (indexes are often not important
for sorting records).

Regards,
Aage J.

Re:BDE vs ADO


Quote
Aage Johansen <aage.johan...@kreftreg.no> wrote in message <news:3EF2B4BE.59063F9B@kreftreg.no>...
> Roger Valand wrote:

> > ...
> > I have experienced the same problem when I am trying to access a table
> > of almost one mill. records. (on Microsoft SQL Server) . The program
> > is taking forever to load.  So long that I don't know how long,
> > because i can't wait.
> > If anyone have the answer, there are two of us that wonder about this
> > problem

> > Regards Roger

> The problem is often that you are using "Table" components with a
> Client/Server database.  TTables are for desktop databases (Access,
> Paradox), or small tables (with C/S databases).  You are probably opening
> one or more (largish) tables early on in the program.
> The solution is to use "Queries" (almost) exclusively.  Don't fetch more
> records (or fields) than the user needs - and he should be prepared to
> provide reasonable criteria for selecting a (small) subset of the records
> in the tables.
> Don't make 'browsing' type apps showing thousands of records in a grid
> (which one may tend to do with a desktop database).  Remember to define
> appropriate indexes for selecting records (indexes are often not important
> for sorting records).

> Regards,
> Aage J.

TTable (BDE Type) works fine.  It's TADOTable that doesn't.  Any idea why?

Bill

Re:BDE vs ADO


Quote
Bill Reynolds wrote:
> Aage Johansen <aage.johan...@kreftreg.no> wrote in message <news:3EF2B4BE.59063F9B@kreftreg.no>...
> > Roger Valand wrote:

> > > ...
> > > I have experienced the same problem when I am trying to access a table
> > > of almost one mill. records. (on Microsoft SQL Server) . The program
> > > is taking forever to load.  So long that I don't know how long,
> > > because i can't wait.
> > > If anyone have the answer, there are two of us that wonder about this
> > > problem

> > > Regards Roger

> > The problem is often that you are using "Table" components with a
> > Client/Server database.  TTables are for desktop databases (Access,
> > Paradox), or small tables (with C/S databases).  You are probably opening
> > one or more (largish) tables early on in the program.
> > The solution is to use "Queries" (almost) exclusively.  Don't fetch more
> > records (or fields) than the user needs - and he should be prepared to
> > provide reasonable criteria for selecting a (small) subset of the records
> > in the tables.
> > Don't make 'browsing' type apps showing thousands of records in a grid
> > (which one may tend to do with a desktop database).  Remember to define
> > appropriate indexes for selecting records (indexes are often not important
> > for sorting records).

> > Regards,
> > Aage J.

> TTable (BDE Type) works fine.  It's TADOTable that doesn't.  Any idea why?

Not really ...  I left the BDE behind (for C/S use) some years ago.  But the BDE did have some smarts
built-in, though.

--
Aage J.

Other Threads