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

Dave

Yup - just like its a disk based table.

Roy

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

"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

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

Dave

>Is ElevateDb the same (memory tables local to process only)?

Yup, and with c/s memory tables on the server.

Roy Lambert

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

"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

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

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