Tim

Is there a reason, apart from consistency with DBISAM, why the in-memory tables definition is removed when you close the app? I just came to a realisation that it would be nice to have all of the table definitions left in the catalog for future use rather than having to recreate them all the time.

Roy Lambert

Roy Lambert wrote:

> Tim
>
> Is there a reason, apart from consistency with DBISAM, why the in-memory tables definition is removed when you close the app? I just came to a realisation that it would be nice to have all of the table definitions left in the catalog for future use rather than having to recreate them all the time.
>
> Roy Lambert

Roy,
   The memory tables are local to the process. That means 10 different
processes could have 10 different definitions of the same table. Which
one should be stored in the catalog?

   Now it would be nice to have a global memory table in DBISAM or
ElevateDb like you can with other databases, but I don't think you can
do that. That would allow the memory table to be shared amongst all users.

Dave

Dave


> The memory tables are local to the process. That means 10 different
>processes could have 10 different definitions of the same table. Which
>one should be stored in the catalog?

If the definition is different the table is different but I accept you could use the same name for different tables. I often create memory tables in threads so I'm used to creating a table with the same structure but a different name and I was just thinking it would be nice to have the template stored somewhere rather than being a part of the program. I would also be happy to DROP the unwanted duplicated myself.

> Now it would be nice to have a global memory table in DBISAM or
>ElevateDb like you can with other databases, but I don't think you can
>do that. That would allow the memory table to be shared amongst all users.

I can see that working in a pure c/s environment with the shared memory on the server but in fileserver .....

Roy Lambert

Roy,

<< Is there a reason, apart from consistency with DBISAM, why the in-memory
tables definition is removed when you close the app? I just came to a
realisation that it would be nice to have all of the table definitions left
in the catalog for future use rather than having to recreate them all the
time. >>

The issue is that the catalog itself is stored in-memory for an in-memory
table, and I'm not sure if customers would like it if we insisted on storing
the in-memory database catalogs on disk.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


That makes sense. I'll have to see if I can master the create table from or whatever it is syntax.

Roy Lambert