Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
Dynamic datasets: tables vs queries |
Sat, Feb 10 2007 3:03 PM | Permanent Link |
Michael Fullerton | DBISAM 3.30
I have some complex data access that needs to take place inside a TTimer. To prevent "collisions" I thought I would use dynamically created TDBISAMTables. However, If the table was very large I wonder if it would actually be faster to use dynamic TDBISAMQuerys instead. This is because on every access to the table you need to open it which takes a long time. I'm not sure exactly what happens when you open a query though. What do you think? Note that in some situations all data access would only be local. In other situations data would be accessed over the network. i.e. programX is only local programY is multi-user. ___ Free Project Time Tracker for Delphi Developers http://www.cybermatrix.com/pcdelphi.html |
Sat, Feb 10 2007 5:39 PM | Permanent Link |
Sam | Michael ,
A query will be slower because the SQL has to be interpreted and then the table open and the query executed. You could use TDBISAMTables but use a connection pool where you get the next available TDBISAMTable (which is already connected to the database). When you are finished with the table, you put it back into the pool. There are plenty of examples if you use tamaracka and search for "connection pool". Here is a simple example: http://www.realthinclient.com/forum/?cmd=viewtopic&topic_id=37§ion_id=1 Sam |
Sun, Feb 11 2007 4:53 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Michael
I'm not sure what you mean by slow can you post the code. In some of my apps I create session, query, table and its fairly fast. Roy Lambert |
Mon, Feb 12 2007 3:37 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Michael,
<< This is because on every access to the table you need to open it which takes a long time. I'm not sure exactly what happens when you open a query though. What do you think? >> Queries will suffer from the same issue and still require a table open. However, there is a solution for both - just make sure that the table is open outside of the TTimer handler code and DBISAM will basically pre-open the table files and internally cache them for you for the subsequent table opens. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Feb 12 2007 4:43 PM | Permanent Link |
Michael Fullerton | On Mon, 12 Feb 2007 15:37:38 -0500, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote: >Michael, > ><< This is because on every access to the table you need to open it which >takes a long time. I'm not sure exactly what happens when you open a query >though. What do you think? >> > >Queries will suffer from the same issue and still require a table open. >However, there is a solution for both - just make sure that the table is >open outside of the TTimer handler code and DBISAM will basically pre-open >the table files and internally cache them for you for the subsequent table >opens. That sounds too good to be true. I have TDBISAMTable components for each table in a DataModule. It sounds like you are saying as long as each of the required tables are opened using these TTable components before the TTimer fires, on creating the dynamic versions of the tables, DBISAM will somehow still use cached versions of the tables. So only one table is cached in memory no matter how many instances (TDBISAMTable objects) of it are created. The other instances are merely different cursors to the one cached table. ___ Free Project Time Tracker for Delphi Developers http://www.cybermatrix.com/pcdelphi.html |
Tue, Feb 13 2007 6:13 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Michael
>That sounds too good to be true. I have TDBISAMTable components for >each table in a DataModule. It sounds like you are saying as long as >each of the required tables are opened using these TTable components >before the TTimer fires, on creating the dynamic versions of the >tables, DBISAM will somehow still use cached versions of the tables. >So only one table is cached in memory no matter how many instances >(TDBISAMTable objects) of it are created. The other instances are >merely different cursors to the one cached table. This was one of the (forgotten until now) things that prompted the switch from Paradox for me. Back in W95/98 days file handles were at a premium. Roy Lambert |
Tue, Feb 13 2007 3:09 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Michael,
<< That sounds too good to be true. I have TDBISAMTable components for each table in a DataModule. It sounds like you are saying as long as each of the required tables are opened using these TTable components before the TTimer fires, on creating the dynamic versions of the tables, DBISAM will somehow still use cached versions of the tables. So only one table is cached in memory no matter how many instances (TDBISAMTable objects) of it are created. The other instances are merely different cursors to the one cached table. >> Provided that the table and query components are all using the same physical database in the same session, yes. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |