Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 22 total |
EDBManager |
Sat, Nov 1 2008 7:49 AM | Permanent Link |
Leslie | Tim,
1. After creating a table by executing a script in EDBManager Unicode 2.02 it dos not persist. After closing and opening EDBManager the tble is not there anymore. The triggers created normaly (not by srcipt) are lost too. 2. I have created an after insert trigger to update a table in a disk based DB according to the changes in a table in the inmemory db. The new line has been created after inserting a record, but none of the field values were assigned to the disk based table. Regards, Leslie |
Sat, Nov 1 2008 11:15 AM | Permanent Link |
Leslie | Tim I have left out the most important info from the previous post. It was an InMemory database I was testing. Regards, Leslie |
Sat, Nov 1 2008 11:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Leslie
This one baffled me as well - I also thought the metadata would be saved, but its not so. It makes sense when you think about it when you close an in-memory database the whole lot goes - data and metadata. Roy Lambert [Team Elevate] |
Sat, Nov 1 2008 2:28 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< I have left out the most important info from the previous post. It was an InMemory database I was testing. >> That's how in-memory databases work. They are completely in-memory, so their contents go away when the process terminates. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Nov 1 2008 4:01 PM | Permanent Link |
Leslie | Tim,
<<<< I have left out the most important info from the previous post. It was an InMemory database I was testing. >> That's how in-memory databases work. They are completely in-memory, so their contents go away when the process terminates.>> (Just to make sure we are talking about exactely the same thing. It was the metadata which I expected to persist, not the data. ) I understand that keeping the catalog and everything else in the memory is important for high performance, but loading the metadata from disk before opening the db would not effect runtime performance, while making database management for memory databases much easier. When designing databases, the natural thing - at least for me - would be to use the same tools the same way to manage the database, no matter where it is stored. I am really not trying to rush the answer - especially not in the weekend - but as you normaly walk through all the posts and answer them one by one: have you considered the trigger related question (2.) in the other post? Is it a bug, or I am doing something wrong ? Regards, Leslie |
Sat, Nov 1 2008 4:27 PM | Permanent Link |
Leslie | Roy,
I am thinking about a possible workaround: Designing the database as a disk based db with EDBMananager, and using it's metadata to create the database in memory. What we need is a general purpose CloneDB procedure. I could think of to possibel ways to archieve that: 1. Querying the system tables and inserting all records to the inmemory system rables. Which may be a bad idea for many reasons. 2. Extracting metadata of the disk db to a script, modifing it a bit and running the script to create the inmemory db. Could any of these work? Regards, Leslie |
Sat, Nov 1 2008 4:31 PM | Permanent Link |
Leslie | <<(Just to make sure we are talking about exactely the same thing. It was the metadata which
I expected to persist, not the data. )>> Looks like I am too tired. We were obviously talking about the same thing. Regards, Leslie |
Sun, Nov 2 2008 2:58 AM | Permanent Link |
Leslie | Tim,
Inmemory database would be a very good way to optimize performance. To do that I need to be able to reference it from the disk based db and to the other way around too. I got the impression that you may be seeing this mostly from an individual programmer's viewpoint. The way it is at the moment from the system designer's viewpoint is something like this: "OK, let's make use of this great inmemory database feature! Oh wait, I cannot design, the only use supported is by direct programming ." Regards, Leslie |
Sun, Nov 2 2008 5:10 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Leslie
>I am thinking about a possible workaround: Designing the database as a disk based db with >EDBMananager, and using it's metadata to create the database in memory. What we need is a >general purpose CloneDB procedure. I could think of to possibel ways to archieve that: > >1. Querying the system tables and inserting all records to the inmemory system rables. >Which may be a bad idea for many reasons. Well, its a good idea apart from one small snag - you can't do it. The system tables can only be maintained using the appropriate syntax. >2. Extracting metadata of the disk db to a script, modifing it a bit and running the >script to create the inmemory db. This way would work, and you can probably use Tim's reverse engineering code as a start point. You could also create the in-memory database tables in a "special" on-disk database, reverse engineer it and store the code and run that in the context of the in-memory database when you start the app. What I tend to do is define the table in the IDE setting persistent fields and I then have a function (it in extensions) which will create the table. I use this approach since I need the same structure table in many places with its own name (usually based on GetTickCount) plus I prefer programming with persistent fields. Roy Lambert [Team Elevate] |
Mon, Nov 3 2008 4:16 AM | Permanent Link |
Leslie | Roy ,
Thank you for your answer. I think I have seen the code for your component capable of creating the database tables. I would like to test it, it is possible workaround. Do you remmber which topic it was, where you shared it? Regards, Leslie |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |