Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Why can't memory tables on the server be seen by other connections?
Thu, Jan 10 2013 5:35 PMPermanent Link

Barry

I created a memory table on the server, filled it with data, and connected to the database from a client. But I don't see any tables or views that I've created. Why?

These tables are behaving like Temporary tables yet I didn't specify a temporary memory table.

What gives?
TIA

Barry
Fri, Jan 11 2013 5:12 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Barry


Memory tables are process (that's an ElevateDB process not a Windows process) specific. For a client to see them it has to be the client that created them.

You can see this at work if you open two instances of EDBManager at the same time and create memory tables in each instance. Each instance can only see its own in-memory tables.

In file/server mode the memory used is the client PC but in client/server mode its the servers.

Roy Lambert
Fri, Jan 11 2013 7:34 AMPermanent Link

Adam Brett

Orixa Systems

Barry

To achieve the result you desire I think you should probably create a second "temporary" database (which is actually permanent on disk!) and create the tables on it. Then use JOBs, or calls to statements from the EXE to create & populate & delete these tables as they are needed.

Yes they will be on disk rather than in memory ... but everyone will be able to see them & they will be logically separated from any permanent tables.
Fri, Jan 11 2013 7:48 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Adam


Interesting thought but personally I'd start by wondering why I wanted any form of temporary table that is shared. Without knowing what Barry's trying to achieve (eg speed ups or sharing the results of an interim query / result set) its difficult to say what is the best approach.

Roy Lambert [Team Elevate]
Fri, Jan 11 2013 11:17 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Barry,

I'll just add to what Roy said:  the reason for this behavior is so that a
local application ported to C/S behaves in the same manner.  The per-process
memory isolation has to be respected, even with the EDB Server.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Jan 11 2013 12:02 PMPermanent Link

Barry

>I'll just add to what Roy said:  the reason for this behavior is so that a
local application ported to C/S behaves in the same manner.  The per-process
memory isolation has to be respected, even with the EDB Server.<

Just to summarize things:

1) What you're saying is all memory tables are really Temporary Memory tables, isolated to the session that created it?
2) On a FS the memory is allocated on the user's machine?
3) On a C/S the memory is allocated on the DB Server?
4) There is no way to share a memory table between users?
5) What happens when a memory table is sorted? Does a temporary table get created on the user's local hard drive?

TIA
Barry
Sat, Jan 12 2013 9:02 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Barry


The answers below reflect only my assumptions - reality may differ - you have been warned


>1) What you're saying is all memory tables are really Temporary Memory tables, isolated to the session that created it?

Temporary - Yes both in the ElevateDB sense as in the sense of transient in nature. Isolate to a process in the ElevateDB rather than Windows sense of the word which I suppose means session. I think it may be possible to share a session across processes (bit hairy though) and what would happen in that case I don't know.

>2) On a FS the memory is allocated on the user's machine?

Yes

>3) On a C/S the memory is allocated on the DB Server?

Yes

>4) There is no way to share a memory table between users?

Not just by pointing a component at it. You can always move the data around though.

>5) What happens when a memory table is sorted? Does a temporary table get created on the user's local hard drive?

Are you talking about running a query? If so it would depend on wether it will produce a sensitive result set or not (I think). Table indices stay in memory so switching index stays in memory.


To ask a question back. What do you want to use in-memory tables for, and why?

Roy Lambert [Team Elevate]
Sat, Jan 12 2013 9:36 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Barry,

<< 1) What you're saying is all memory tables are really Temporary Memory
tables, isolated to the session that created it? >>

No, they're isolated to the *process* that created it.  EDB sends over
process information to the EDB Server, so it knows how to segment things by
process.

<< 2) On a FS the memory is allocated on the user's machine? >>

Well, with a local session, yes, it is allocated on the user's machine as
part of the application process.

<< 3) On a C/S the memory is allocated on the DB Server? >>

With a remote session, yes.

<< 4) There is no way to share a memory table between users? >>

No, at least not currently.  See this thread for more on this:

http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&msg=15325&page=1

<< 5) What happens when a memory table is sorted? Does a temporary table get
created on the user's local hard drive? >>

Do you mean what happens when a memory table is queried and generates an
insensitive result set ?  In such a case, the result set is also in-memory.
With DBISAM, this is not the case.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Image