Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
In memory tables |
Tue, May 1 2007 11:17 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, May 1 2007 2:41 PM | Permanent Link |
Dave Harrison | 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 |
Wed, May 2 2007 3:27 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Wed, May 2 2007 11:48 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, May 2 2007 12:19 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
That makes sense. I'll have to see if I can master the create table from or whatever it is syntax. Roy Lambert |
This web page was last updated on Monday, May 6, 2024 at 03:23 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |