OK, now seems to be all sorted.
Just need to do some final and serious testing tomorrow.

Malcolm,

<< I simply forgot that for c/s all temp tables are saved on the server host. With f/s I had them on the 'client' host even when using a remote host database so only had to manage them in the context of a single user.

So I now I think I have to name them with some client ID prefix, perhaps hostname, in order to avoid any clash. >>

If you use temporary tables (CREATE TEMPORARY TABLE), you'll get all of the benefits without any of the downsides.  You can refer to them the same as normal tables, but they are stored in the temporary tables path using a unique file name that you don't have to worry about.  And, they're session-specific, so no other session will see these tables.

Tim Young
Elevate Software
www.elevatesoft.com

Raul,

Ha, I was going to correct this:

"In such a situation, ElevateDB will create a temporary table that is only visible to the current session, but is
still entirely in-memory."

but then I realized that a) I wrote it, and b) it's correct.  The past me should skip forward and slap present me.

BTW, I think I've got a way to manage upgradeable read-write locks in both DBISAM and ElevateDB, and that will improve the performance of table opens/closes to some degree, especially if a particular table is a hot spot and is constantly being opened and closed by multiple threads.  As I mentioned, I saw this with the EWB web server load testing when using DBISAM, and it also affects ElevateDB.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> If you use temporary tables (CREATE TEMPORARY TABLE), you'll get all
> of the benefits without any of the downsides.  You can refer to them
> the same as normal tables, but they are stored in the temporary
> tables path using a unique file name that you don't have to worry
> about.  And, they're session-specific, so no other session will see
> these tables.

Thanks Tim, I finally got my head around it and it is doing exactly
what I want.

What delayed me was my confusion about the meaning of the Help where it
talks about these temp tables only being visible to the session.  I
simply misunderstood that the session scope was equivalent to the
client (in my context).  Yeah, dumb, but there I go again - expecting
it to be harder.  :/

I am sure you know you've done a first class job, but you probably like
to read it anyway.  <bg>

Malcolm,

<< What delayed me was my confusion about the meaning of the Help where it talks about these temp tables only being visible to the session.  I simply misunderstood that the session scope was equivalent to the client (in my context).  Yeah, dumb, but there I go again - expecting it to be harder.  :/ >>

 It's a rare occurrence, but some applications *do* require multiple sessions (EDB Manager is one of them), and so the manuals have to account for this everywhere.

<< I am sure you know you've done a first class job, but you probably like to read it anyway.  <bg> >>

Yes, yes I do.  Thanks !

Tim Young
Elevate Software
www.elevatesoft.com