Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
TClientDataSet or TEDBQuery |
Fri, Sep 11 2009 7:06 AM | Permanent Link |
Peter | 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 |
Fri, Sep 11 2009 12:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Sep 11 2009 7:16 PM | Permanent Link |
Peter | 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 |
Mon, Sep 14 2009 12:11 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |