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

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&section_id=1

Sam

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

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

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

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

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