Not sure I quite understand this: If I assign an SQLite database in Session does it put the database on the client side? If not, can I put a database on the client side?
@John S Not sure I quite understand this: If I assign an SQLite database in Session does it put the database on the client side? If not, can I put a database on the client side?
You can’t. The web browser makers shied away from WebSQL in favor of IndexedDB to prevent reliance on a particular technology unfortunately.
@Markus R i believe spider basic use a memory db and then in can save/load it in to browser cache sandbox. (non persistence at all)
It uses sql.js (as I linked to above) when you compile a web app or SQLite if you're compiling for Android / iOS.
With web apps it's only persistent until the user clears their browser cache, with Android / iOS then it's truly persistent in a local SQLite file.
As I said speed; so that the program can get information from the client computer instead of constantly sending an sql command to the server.
I think that will speed things up . . . Am I wrong? (remember, knowledgeable amateur here, not like you professionals)
Uhm, I think the problem is we're proposing solutions to a problem we don't know. What's the actual speed issue you're trying to resolve John?
If you cache database results into arrays (that will live in the server), then you will have to figure out how you'll invalidate the cache when needed. Put the cached array into cookies, and you'll end up reaching the browser's cookies size limit sooner or later.
Speeding up an application needs a profiling analysis. You can profile the server side using fantastic Xojo's tooling, or the Browser's Developer Tools for the client side. Write down a list of the performance issues you've detected, estimate the effort on fixing them. Then you'll be able to just attack the less effort/most impact solution. Rinse and repeat.
For example (just an example I don't know your issue), maybe you're trying to put the DB into the client because the queries you're doing are CPU intensive and you're running out resources on your server, so you can offload the effort to the clients. The solution instead may be adding an index here or there, rewriting the query, using a materialized view, etc.