Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 12 total |
Can I have 2 memory tables pointing to the same memory table? |
Sat, Jul 7 2007 4:29 PM | Permanent Link |
Dave Harrison | I need to have 2 memory tables pointing to the same memory table. Is
this possible? I bet this hasn't been asked before I need to traverse the first memory table and use the second memory table to append rows to it. If I try and do this with only 1 memory table (traverse it and append rows to it), right after the row is appended, the table gets EOF (even though the range does not permit it to see the newly appended record). If this were a regular disk based table then I could simple have two TDBISAMTable comonents pointing to the same disk file. But I'm not sure if this is going to work if I'm pointing to the same memory based table. Will this work? Dave |
Sun, Jul 8 2007 4:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dave
Yup - just like its a disk based table. Roy |
Sun, Jul 8 2007 11:18 PM | Permanent Link |
Dave Harrison | Roy Lambert wrote:
> Dave > > Yup - just like its a disk based table. > > Roy > Roy, Ok great. But does this also mean that these memory tables can be located on the server so more than one machine can access them at the same time? Or are memory tables only local to the process that created it? Dave |
Mon, Jul 9 2007 6:07 AM | Permanent Link |
"Robert" | "Dave Harrison" <daveh_18824@spammore.com> wrote in message news:C7B9A2ED-7F3B-4427-943A-6618344959F2@news.elevatesoft.com... > Roy Lambert wrote: >> Dave >> >> Yup - just like its a disk based table. >> >> Roy >> > > Roy, > Ok great. But does this also mean that these memory tables can be > located on the server so more than one machine can access them at the same > time? Or are memory tables only local to the process that created it? > "memory" is just another database, so memory tables can be accessed just like any other DBISAM table. But as opposed to disk tables, they are only available to the process (I think it is to the session, read the docs) that created them. And they are destroyed when that process ends. So the answer to your question is no. If you need to make tables persist and/or be shared between programs, you need to place them on disk or otherwise figure a way to transfer the data between the two progams' memory. Robert |
Mon, Jul 9 2007 10:06 AM | Permanent Link |
Dave Harrison | Robert wrote:
> "memory" is just another database, so memory tables can be accessed just > like any other DBISAM table. But as opposed to disk tables, they are only > available to the process (I think it is to the session, read the docs) that > created them. And they are destroyed when that process ends. So the answer > to your question is no. If you need to make tables persist and/or be shared > between programs, you need to place them on disk or otherwise figure a way > to transfer the data between the two progams' memory. > > Robert Robert, Ok, that's what I thought. This is contrary to how other databases handle their memory tables (MySQL, NexusDb, etc.) which can be shared between machines/users just like any other table. I suppose it has something to do with DBISAM locking, or likely not having locking on its memory tables. Is ElevateDb the same (memory tables local to process only)? Dave |
Mon, Jul 9 2007 11:06 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dave
>Is ElevateDb the same (memory tables local to process only)? Yup, and with c/s memory tables on the server. Roy Lambert |
Mon, Jul 9 2007 4:18 PM | Permanent Link |
Dave Harrison | Roy Lambert wrote:
> Dave > > >>Is ElevateDb the same (memory tables local to process only)? > > > Yup, and with c/s memory tables on the server. > > Roy Lambert I think I've got it. "The rain in Spain falls mainly..." oops, sorry. I was caught up in an old Rex Harrison flashback. I meant to say if I create a memory table with DBISAM C/S, the memory table gets shared on the server and is always shareable. If I create a memory table with DBISAM LAN it gets seen only by the process and never shared by any other machine. So depending on the visibility I need for the memory table, I'll choose either LAN or C/S using a different engine. This seems a bit awkward at first because the other database products I've used in the past, can use the same engine and I can control the visiblity of the memory table when the table is created, using the same engine. I suppose if the developer wants the DBISAM memory table to be shared by more than 5 users, he'll have to buy the C/S version even though a LAN version may be serving up the rest of his tables. Dave |
Mon, Jul 9 2007 4:27 PM | Permanent Link |
"Robert" | "Dave Harrison" <daveh_18824@spammore.com> wrote in message news:E4506987-E85E-44B3-8829-1A58B9764718@news.elevatesoft.com... > > I meant to say if I create a memory table with DBISAM C/S, the memory > table gets shared on the server and is always shareable. If I create a > memory table with DBISAM LAN it gets seen only by the process and never > shared by any other machine. So depending on the visibility I need for the > memory table, I'll choose either LAN or C/S using a different engine. > > This seems a bit awkward Mostly because it is not true Both work exactly the same way. The memory tables are available ONLY to the process that creates them, whether it is file sharing or C/S. In C/S the table is in the server's memory, instead of the workstation, which can create some issues under some circumstances. But for all practical purposes, DBISAM file sharing or C/S are the same, from a programming point of view (I know, I know, in C/S you can do server side programming, but that's another story). > engine. I suppose if the developer wants the DBISAM memory table to be > shared by more than 5 users, If you need for a table to be shared by more than one program, you need to create it on disk, not memory. Robert |
Mon, Jul 9 2007 5:08 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< Ok great. But does this also mean that these memory tables can be located on the server so more than one machine can access them at the same time? Or are memory tables only local to the process that created it? >> In-memory tables are local to the process that created them, regardless of whether you're using local or remote session(s) to create/access them. The only difference is that local sessions create their in-memory tables in the local machine memory whereas remote sessions create their in-memory tables in the database server machine's memory. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Jul 9 2007 6:09 PM | Permanent Link |
Dave Harrison | Tim Young [Elevate Software] wrote:
> Dave, > > << Ok great. But does this also mean that these memory tables can be located > on the server so more than one machine can access them at the same time? Or > are memory tables only local to the process that created it? >> > > In-memory tables are local to the process that created them, regardless of > whether you're using local or remote session(s) to create/access them. The > only difference is that local sessions create their in-memory tables in the > local machine memory whereas remote sessions create their in-memory tables > in the database server machine's memory. > So if I have a multi-threaded webserver and I want to share the memory table with each connection, how do I do that without creating copies of the same memory table and filling it with the same rows? Each connection of course gets its own datamodule. Dave |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |