Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
In-Memory Table Memory |
Mon, Aug 10 2020 4:38 PM | Permanent Link |
Dale Derix | 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 |
Tue, Aug 11 2020 4:00 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Aug 11 2020 9:52 AM | Permanent Link |
Dale Derix | 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 |
Tue, Aug 11 2020 11:58 AM | Permanent Link |
Raul Team Elevate | 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 |
Wed, Aug 12 2020 12:18 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Wed, Aug 12 2020 12:23 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Wed, Aug 12 2020 5:48 PM | Permanent Link |
Dale Derix | 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 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |