Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 3 of 3 total |
Clarification on Memory Tables |
Mon, Nov 20 2006 7:08 PM | Permanent Link |
"Adam H." | Hi,
I think I understand this, but just wanted clarification before I stuffed up something. Running DBISam 4 In my application - I run various reports, that do "queries on queries". The SQL looks like: -------------------------- select afield, anotherfield into Memory\tmp1 from Mytable ; select sum(afield), anotherfield from Memory\tmp1 group by anotherfield -------------------------- OK - the real sql's look a little more complex, but you get the idea. So far, I have been running DBISam in local mode. I only have a problem if I use the same memory table name in more than one TDBISamQuery table, when more than one is opened from the same application. (Which is what I would expect). My questions are: 1) If I run queries that insert data into memory using client/server mode (off a DBISam server) - where two users on different machines run the same query, with the same memory table name - I assume there are two seperate processes running on the DBISam server, and this will not cause any conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory 'areas') If this is correct - is this the case if I have two users, on two machines, logging into DBISam server using the same username & password? and... 2) If I have users running of Terminal Service Sessions (using Local mode) - does each user have their own unique memory table area too? From what I can gather, all scenario's above should be seperate - the only problem being if the *same* application instance tries to run queries inserting into the same tablename - but I just wanted to clarify. Thanks Adam. |
Tue, Nov 21 2006 4:13 AM | Permanent Link |
"Jose Eduardo Helminsky" | Adam
I think you will wait for Tim answer but... > 1) If I run queries that insert data into memory using client/server mode > (off a DBISam server) - where two users on different machines run the same > query, with the same memory table name - I assume there are two seperate > processes running on the DBISam server, and this will not cause any > conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory > 'areas') > > If this is correct - is this the case if I have two users, on two > machines, logging into DBISam server using the same username & password? Yes, this is correct. Two processes, two sessions, and therefore two memory tables created, one for each user. > 2) If I have users running of Terminal Service Sessions (using Local > mode) - does each user have their own unique memory table area too? Yes, each user has it own memory area. Eduardo |
Tue, Nov 21 2006 1:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< 1) If I run queries that insert data into memory using client/server mode (off a DBISam server) - where two users on different machines run the same query, with the same memory table name - I assume there are two seperate processes running on the DBISam server, and this will not cause any conflicts. (ie - 2 seperateconnections mean 2 unique seperate memory 'areas') >> It is threads, not processes, running on the database sever, but yes, you are correct. << If this is correct - is this the case if I have two users, on two machines, logging into DBISam server using the same username & password? >> No, internally DBISAM keeps them separated by process ID, not user name. << 2) If I have users running of Terminal Service Sessions (using Local mode) - does each user have their own unique memory table area too? >> Yes. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, April 18, 2024 at 10:42 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |