Hi,

I have been searching the forums for an answer to this but am just getting more confused.

My remote app connects to an edb server. Then in the remote app, I want to create some in-memory tables, but I want them to use the memory on the Client machine, not the server's memory. Is this how it works? Or will the remote app still be using memory on the server machine?

Do I need to set up two sessions.... one for the remote connection, and the second for local?

Thanks,

Dale

Dale

>Do I need to set up two sessions.... one for the remote connection, and the second for local?

AFAIK this is the solution - memory tables are created on the machine that creates them.

Depending on how you intend to populate the in-memory table you may well be better off leaving them on the server, or using temporary tables instead.

Can you give us a bit more information on your use case?

Roy

Roy Lambert wrote:

Hi Roy

<<Can you give us a bit more information on your use case?>>

I used them a lot with DBISAM but now I'm moving to C/S and want to make sure they won't contribute to chatter across the network. Temporary tables would work as well, but I just like the idea of having them in memory instead of them hitting the disk. They are mostly smaller tables for lookups and for building some reports.

Dale

On 8/11/2020 9:52 AM, Dale Derix wrote:
> I used them a lot with DBISAM but now I'm moving to C/S and want to make sure they won't contribute to chatter across the network. Temporary tables would work as well, but I just like the idea of having them in memory instead of them hitting the disk. They are mostly smaller tables for lookups and for building some reports.

Temporary tables are mostly in memory also - i recall Tim saying that
they will not write to disk as long as that can be avoided.

Depending on your queries if you end up with insensitive result then it
might still use disk for temp storage - not 100% certain though on this.

Otherwise main difference is that unlike DBISAM you can have any in
memory database now (vs a single fixed "MEMORY" one in DBISAM).

Local session is best way to ensure no network traffic but then you need
to populate it yourself (save/load stream or just in code).

And they are still accessible for all local sessions (not just one that
created them) unless they are temporary.

Raul

Raul

>Temporary tables are mostly in memory also - i recall Tim saying that
>they will not write to disk as long as that can be avoided.

That's a bit strange since I know they can leave junk behind if the app / server crashes. Not the case with in-memory tables - shutdown anyway and they're GONE.

>Depending on your queries if you end up with insensitive result then it
>might still use disk for temp storage - not 100% certain though on this.

I thought any insensitive query would write to disk, but like yourself I'm not certain.


>Local session is best way to ensure no network traffic but then you need
>to populate it yourself (save/load stream or just in code).

>And they are still accessible for all local sessions (not just one that
>created them) unless they are temporary.

Point of clarification - not an ElevateDB session - a user session (took me a while to twig to that)

Roy

Dale


>I used them a lot with DBISAM but now I'm moving to C/S and want to make sure they won't contribute to chatter across the network. Temporary tables would work as well, but I just like the idea of having them in memory instead of them hitting the disk. They are mostly smaller tables for lookups and for building some reports.

If you're using navigational methods you're possibly right BUT if you want to use SQL remember a query / script is limited to a single ElevateDB session - multiple databases but one session.

You may find it pays to leave everything on the server.

Roy

Hi Roy:

<<You may find it pays to leave everything on the server.>>

Actually, I want to intentionally keep them "off" of the server as there is no need to add to network congestion for what I want them for. And I don't want them to leave around any clutter on the disk in case of a crash or improper shutdown (I learned about that from some of your previous posts about temporary tables

Dale