Hello,

I am trying to decide if I am OK using TEDBEngine.ConfigMemory := true or if I should be using TEDBEngine.UseLocalSessionEngineSettings := true instead.

I have up to 4 different database that I need to connect to.  All in different locations.  The code is working fine now with keeping the configuration in memory (ConfigMemory := true).  At application startup I add all of the existing database to the Engine - each database has its own session component.

My concern is this comment from the documentation: All applications accessing the same databases must use the same configuration file. Failure to do so will result in locking errors.

Our application is designed to have the database local, but in some cases we have users who move the database to a server and point 2 or 3 clients to that location.  With DBISAM this worked OK.  We occasionally had users with corrupt data files but that was OK as these tables are just a cache that can be rebuilt. We would tell users if they didn't want to rebuild the cache to buy our actual server version

Will locking work correctly if the Engine configuration is held in memory (by all clients - I understand I can't mix and match) and clients on two different machines connect to a network drive?  I'm worried that the locking can't happen if there is no configuration file on disk.

Is there any other downside to using ConfigMemory instead of UseLocalSessionEngineSettings?

Thanks,

Mark Elder

I have switch over to UseLocalSessionEngineSettings.  Posting this here in case it is useful to others.

In my case I have two copies of the same database.  My application lets users move records from one database to the other.  When trying to use the ConfigMemory I could only add one of the Databases because I was using the same database name.  I was thinking the having individual sessions would keep the databases separate and when setting the DatabaseName and SessionName on a query object that I would end up in the right physical database.  

However, as far as I can tell the Engine needs a unique database name for every database that is added.  Switching from ConfigMemory to UseLocalSessionEngineSettings lets me keep the same database name in different sessions.

I didn't ever figure out how this would affect locking but I'm not really worried about that now since I have disk based engine files for each of my databases.

Thanks,

Mark

Mark,

<< Will locking work correctly if the Engine configuration is held in memory
(by all clients - I understand I can't mix and match) and clients on two
different machines connect to a network drive?  I'm worried that the locking
can't happen if there is no configuration file on disk. >>

Yes, it will still work as long as all clients are using ConfigMemory=True.
What happens when you use a virtual configuration is that the session
locking/handling is pushed off on to the individual databases instead of
being negotiated at the configuration level.

<< Is there any other downside to using ConfigMemory instead of
UseLocalSessionEngineSettings? >>

No.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mark,

<< I have switch over to UseLocalSessionEngineSettings.  Posting this here
in case it is useful to others.

In my case I have two copies of the same database.  My application lets
users move records from one database to the other.  When trying to use the
ConfigMemory I could only add one of the Databases because I was using the
same database name.  I was thinking the having individual sessions would
keep the databases separate and when setting the DatabaseName and
SessionName on a query object that I would end up in the right physical
database.

However, as far as I can tell the Engine needs a unique database name for
every database that is added.  Switching from ConfigMemory to
UseLocalSessionEngineSettings lets me keep the same database name in
different sessions. >>

Just so you know, you *can* use both, so if you want to have separate
sessions using the same database names, but pointing to different locations,
*and* use a virtual configuration file, you can do so.

--
Tim Young
Elevate Software
www.elevatesoft.com