Hello

I have used a ClientDataset in an IBase application where I can show only one client record at a time, out of 150k records. There are 4 other
ClientDatasets holding small detail resultsets that are populated at the same time as the current client record is changed. The IBase app uses StoredProcs
to populate all the ClientDatasets; all cursors are insensitive - editing is done by opening forms with non data-aware cotrols, inserting\updating then calling
all the StoredProcs to requery the new\edited record.

On the other hand, I used DBISAM in-memory tables in the same app at one stage, but the speed was unacceptable on low spec (<1 Gb RAM) machines,
so I moved on without further investigation. Many of my clients have coal fired computers.

The new app will have the same data as in the IBase app, and the same arrangement, but I am unsure about whether I should bother with ClientDatasets.
I am not going to Unicode just yet; there has been talk of Unicode problems with ClientDatasets.

In your opinion, which is the best component\design for such an app?

Regards

Peter

Peter,

<< On the other hand, I used DBISAM in-memory tables in the same app at one
stage, but the speed was unacceptable on low spec (<1 Gb RAM) machines, so I
moved on without further investigation. Many of my clients have coal fired
computers. >>

What part of the speed was unacceptable ?  The performance of the queries to
populate the in-memory tables, or the usage of the in-memory tables
themselves ?

You should be able to use straight-up ElevateDB queries or tables/views to
do what you want without any issues with performance, that is what you
ultimately want to do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<<What part of the speed was unacceptable ?  The performance of the queries to
populate the in-memory tables, or the usage of the in-memory tables
themselves ?>>

The latter. 40ms to populate a grid on my 2Gb XP machine, 51 seconds on a 500 Mb RAM XP machine.

<<You should be able to use straight-up ElevateDB queries or tables/views to
do what you want without any issues with performance, that is what you
ultimately want to do.>>

Ok, that makes sense, thanks for the advice.

Regards

Peter

Peter,

<< The latter. 40ms to populate a grid on my 2Gb XP machine, 51 seconds on a
500 Mb RAM XP machine.  >>

Was this DBISAM 3.x ?  If so, then DBISAM 4.x corrects this, and so does
ElevateDB.  Both use a block-oriented internal structure for in-memory
tables, whereas 3.x used a linear memory allocation scheme that only worked
well with small tables.  If you tried to add a bunch of rows to an in-memory
tables (10,000 or more), you would start to experience serious performance
issues.

--
Tim Young
Elevate Software
www.elevatesoft.com