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
 

Tim

I have left out the most  important info from the previous post.  It was an InMemory
database I was testing.

Regards,
Leslie
 

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]

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

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

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

<<(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

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
 

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]

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