OK, this one got me.  
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 I am correct, does anyone have a particularly elegant method of
naming these tables?

Malcolm

Malcolm


I'm not sure but TEMPORARY tables may be your answer, it depends on how they're being created  The reason I'm not sure is that it may only apply to in-memory tables. A while back, at the request of users, Tim allowed in-memory tables to be shared. They could be isolated between users by using CREATE TEMPORARY

Just found a post from Tim back in 2009. The relevant point is

<<As for other users - each temporary table is session-specific.>>

As I say, I'm not 100% positive what happened but worth checking out


If temporary tables aren't usable the only (almost) guaranteed unique name is a guid. In the past I  have used GetTickCount with a prefix - not good but clashes are fairly unlikely, User ID with a counter, a function specific prefix (eg mailmerge) with an application maintained counter (an entry in my config db)

Roy Lambert

Roy Lambert wrote:

> <<As for other users - each temporary table is session-specific.>>

I did see that somewhere.  But yesterday I got 'bit in the b*m' when 3
users, all on client hosts connected to the server, created *temporary*
tables named "RUNORDER".   Blooey!  Then I remembered seeing something
about this a few years ago.

So, this morning I read the Help and searched here in the hope that I
couild find a clear guide on this issue .. but I must have missed it.
I think that a memory database has the same issue, it gets created on
the server host - but maybe I could have each client create a unique
one for the purpose .. if it is worth the effort.  Seems just as easy
to prefix a client identifier to each temp table they create.

If I am wrong please tell me.  

Malcolm


>So, this morning I read the Help and searched here in the hope that I
>couild find a clear guide on this issue .. but I must have missed it.
>I think that a memory database has the same issue, it gets created on
>the server host - but maybe I could have each client create a unique
>one for the purpose .. if it is worth the effort. Seems just as easy
>to prefix a client identifier to each temp table they create.

As I recall it the user was supplying an US government department and part of the spec was some sort of user databases so that the table names could be kept the same - hmmmm.

My memory says that it was related to in-memory tables but I'm not sure, and searching the newsgroups results in to many hits for me to read through without pay

Just to be absolutely clear are the tables "temporary" created with CREATE TABLE or TEMPORARY created with CREATE TEMPORARY TABLE?

Roy

Roy Lambert wrote:

Hang on a minute .. or longer.  

I need to do some more debugging because I now see the exception
relates to a Memory Database table.
I had forgotten that I even used a Memory database.

Head scratching .. ah it is time for lunch .....

Bingo!

Found an old post from Tiago, clearly stating .. 'temporary tables are
only visible to the current session'.
So I guess that each client creating a temporary table (CREATE
TEMPORARY TABLE) named 'MYONE' actually gets a private copy through
Tim's magic (sessionID?).

If that is correct I will be happy.

My error seems to have been to keep on using a Memory Database which I
think does what I wanted in F/S, but not in C/S ... maybe.

My latest testing of temporary tables under C/S seems to allow multiple
users to operate independently on the identically named temp tables.  

So, now to try replacing my MemoryDB tables with plain Temp
tables........

Malcolm


You're not reading my posts correctly (think iPhone gag)

Initially any MEMORY tables were specific to a session (roughly = user) then a change was made so that MEMORY tables could be shared just like disk based ones then TEMPORARY tables in MEMORY were changed so that those were specific to a session again.

So the real decision is 1. do you have enough memory on the server to handle whatever temporary tables you create and 2. will you gain any benefit from it (with c/s and the memory tables residing on the server I doubt it) and 3. if you use sql rather than navigational code is the fact that you have to address two different databases worth it (with temporary disk tables its transparent)

Roy Lambert

Roy

Under F/S I was using a small MemoryDB to provide individual users with
their own, private, non-temporary tables for miscellaneous use.

That appears to have broken under C/S so now they are trampling over
each other' data.  So what's the fix?

1)  From what you suggest, maybe I need only change the existing
MemoryDB code to include TEMPORARY when creating these tables at
run-time.  That would be very easy for me and I doubt the memory
requirement will change from the F/S version.

2)  Or do I simply throw away the MemoryDB and use (the equivalent)
TEMPORARY tables in the (main) database?

As you can tell, I am now rather confused.  

On 11/5/2017 11:26 AM, Malcolm wrote:
> That appears to have broken under C/S so now they are trampling over
> each other' data.  So what's the fix?

This is documented in release notes  - see if this helps :

2.12 Breaking Changes

In-memory databases are no longer isolated by client process in the
ElevateDB Server as of the 2.12 release. This means that the contents of
an in-memory database are visible to all sessions in the ElevateDB
Server. This change was done to fix an issue with increasing memory
consumption on the ElevateDB Server, but also to provide a shared
in-memory storage platform that should prove to be very useful in many
situations.

Information : If you still need per-session, in-memory tables for use
with your application, then you should create a temporary table in an
in-memory database. In such a situation, ElevateDB will create a
temporary table that is only visible to the current session, but is
still entirely in-memory.

Raul

Raul wrote:

>
> This is documented in release notes  - see if this helps :
>
> 2.12 Breaking Changes
>
> In-memory databases are no longer isolated by client process in the
> ElevateDB Server as of the 2.12 release. This means that the contents
> of an in-memory database are visible to all sessions in the ElevateDB
> Server. This change was done to fix an issue with increasing memory
> consumption on the ElevateDB Server, but also to provide a shared
> in-memory storage platform that should prove to be very useful in
> many situations.
>
> Information : If you still need per-session, in-memory tables for use
> with your application, then you should create a temporary table in an
> in-memory database. In such a situation, ElevateDB will create a
> temporary table that is only visible to the current session, but is
> still entirely in-memory.
>
> Raul

Thanks Raul, that is absolutely clear.
I do not need in-memory tables, I just need user isolation.
So I now believe my solution is to scrap the Memory database and
replace those few tables by temporary tables.