@Kristin G At this point, I'm inclined to believe that the best solution for a multi-user business application is a REST/JSON server (Xojo or otherwise) and a Xojo client app whenever a rich, platform-specific UI is desired and direct hardware access may be required.
I had been planing something similar to Markus (the OP)
That you posted made sense to me and what I planned to do using an AloeExpress (Xojo) server, until Thom's warnings... Now I'm not sure now which is best.
Oh, and if your wifi network is spotty, caching a local copy of the database is not the solution (IMHO)... a better wifi network is.
If only that were an option in my situation!!!
BTW I am starting to question if JSON is the best solution to return data to the client if the both the client and the server are written in Xojo. In that case does not have to work within the confines of what browsers and other toys of servers can do.
What I was thinking of was writing record set data to a memory block and sending the binary data to the client...
That could be done 2 ways...
Write a server side class that takes a recordset and writes the records to a memoryblock with header of filenames and datatypes
On the client side a write class that takes the binary string and shoves it into an internal memoryblock. This could allow iteration through the records just like a RecordSet using either and index or fieldnames to access the field data again like a recordset. Under the hood it could be accessing the data under the hood directly from the memoryblock
The other approach would be the same basic idea but writing code to write classes that does that for specific queries (Where field names and datatypes are known upfront) for both the client and server. One would feed the Code writing app a recordset and it would spit out the classes to be imported into client and server apps.
That has the advantage of not needing to send filename and data types as the receiving class would know them. The Client class would have computed properties (or getter methods) so one could use autocomplete in the client code for the fields.
Automating the class production (once written and debugged) could be a real client coding productivity booster I think!
In fact I may do both because I can see situations where one or the other would be best...
It seems to me this type of approach (Recordset data in a binary format Xojo can directly write and read) would be faster and less memory and CPU intensive on the server, as well as resulting is smaller (so less network traffic) payload to send to the client, than converting to (and from) JSON (or XML).
Am I wrong? Is there a strong reason not to do things that way if one uses a Xojo server? If one is using a non Xojo code server that it likely would not be that efficient)