Icon In-Memory Tables

Introduction
DBISAM provides a complete and seamless in-memory table implementation within the same framework as disk-based tables. There are only a few slight differences that should be taken into account when using in-memory tables, and these are detailed below.

DatabaseName Property
The DatabaseName property in the TDBISAMTable and TDBISAMQuery components should always be set to the special in-memory database name "Memory" in order to create or access any in-memory tables. All in-memory tables reside in this same virtual database that is global to the application process. This means that if you create an in-memory table called "mytable" using the TDBISAMTable CreateTable method and then try to create it again elsewhere within the same application, you will receive an error indicating that the table already exists. Because in-memory tables are global to the process, multiple sessions can access and share the same in-memory tables.

Sharing In-Memory Tables
In-memory tables can be shared just like regular disk-based tables. They are also thread-safe and exhibit the same locking and access behaviors.

Creating In-Memory Tables
Just like disk-based tables, in-memory tables must be created before they can be opened.

Deleting In-Memory Tables
Just like disk-based tables, in-memory tables must be deleted if they are no longer needed. If for any reason an in-memory table is not deleted during the execution of an application, DBISAM will automatically delete it when the application process is terminated.

Local and Remote In-Memory Tables
There are no differences between using in-memory tables with local sessions and using in-memory tables with remote sessions other than the fact that in-memory tables created within a remote session are stored on the database server whereas in-memory tables created within a local session are stored locally in the application's memory space.
Image