Data Persistence

[Bob Sneidar]

That's an interesting strategy. I'm gonna mull over this and see if I can find an application for it. The first thing that comes to my mind is that when I am in the field, I sometimes cannot connect to my database, because the customer network is heavily firewalled, and my cell phone can't get a good connection to be used as a hotspot. 

I have thought about adding a "Work Offline" option, and taking all the data I currently have queried, and migrating it to memory databases, then synching up later might be an option. I'd have to lock writes somehow on the offline records in the parent DB, so I don't have to deal with conflicts, and I'd have to prevent certain operations while offline, but it's doable. 

Bob S


> On Jul 30, 2018, at 15:14 , Mike Bonner via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> No, the memory db is in memory, the file db is still a file.  Also forgot,
> you should probably quote the filename 'pathtofile.db' otherwise it gets
> confused (unless you use a file with no extension.
> 
> The nice thing about this is you can have your nice persistent file db,
> open a memory db, then do a create table main.tablename as select * from
> attachedtable.tablename at which point you have the speed benefits of using
> an in memory database.  Just gotta keep both updated if you make changes
> that need to be persistent, but thats no different than loading an array,
> and having to keep the disk based encoded array up to date with changes.
> Faster if anything since you don't have to write the whole thing every time.