Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 8 of 8 total |
Why can't memory tables on the server be seen by other connections? |
Thu, Jan 10 2013 5:35 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |