Steve,

When you work remotely is it during off hours, when you know that there are no other users clients connected to your server?

Quote:


Yeah, in both cases the data you seek to update/export needs to be sent from the server to the client - just like file sharing.


Quote:


No, you were upset yesterday, so I thought I would look into some ways to make your remote operations go more smoothly. For example, if you know that you are the only user, you do not have to use client / server, if you are more comfortable with standalone. You can access a windows server (or Linux server if it is running a SMB server) through an internet connection as though it is part of your local network - using Win32 file sharing. If your server is at address 192.168.0.1 and is listed as a member of your local net (add its address to your workgroup) you can access a sesame application on the server in standalone mode with:

sesame //192.168.0.1\SharedDrive\Sesame\Data\MyDatabase.db

Of course, you cannot have another Sesame server (or client) accessing that application at the same time (hence my question). You would need to setup up an appropriate entry in your rootdirs.ini file and an appropriate image path in your application. But in the end, given that much of the work you are doing is design work - not data entry, and that you are not actually sharing the application while you are working on it remotely, this may end up being significantly simpler for you.

Again, if you are not sharing the application while you are working on it, a good solution may be to use a "key drive". We use them here daily. Mine is a small USB device that holds up to 256 Meg. It is instantly recognized on both Windows and Linux and can copy several Meg a second. It cost less than $100 and fits easily in a pocket.

Client / Server operation in general is intended for simultaneous data entry. Simultaneous design, which may be in-line with data entry, cannot be simultaneous to other design operations on the same application (in any package). Allowing client / server design operations, is for that reason, of course, very controversial, and rare. It is especially rare in packages that allow "tables" (what we call "record definitions") to be defined through trivial user interaction, like designing a form (as opposed to using a controlled command line interface (ala SQL Server, MySql, or Oracle).

To allow the broad flexibility of operations and the fine grain record locking required for simultaneous access across all operations, while yet prevent "data collisions" and inter-user interference, Sesame implements a similar scheme as was done in Q&A. Q&A implements multi-user through file sharing. This means that the database file itself is completely inert and can not "decide" or "act" in any way. Instead, each "engine" as embedded in Q&A checks the state of a counter in the database file, that indicates the operations that are allowed or disallowed based on the number of users having "opened" that application.

Since Sesame only locks at the record level, as opposed to the operational level, it is not concerned with the number of users, or what operations they are performing, but rather the number of engines that simultanously are accessing the data. The rule is that only one engine can ever have the application "open" at a time, yet that engine can have as many users as your license allows. Thereby, the need for the "sunlock" utility. Just like Q&A keeps a count of the number of users, Sesame's engine keeps a flag indicating that the file is already possessed by an engine.

In Q&A, if the "engine" goes down inside one or more clients, the count in the file is incorrect. But, because the file will be closed on shutdown/reboot - the next Q&A "client" can determine that the count is incorrect - a closed file cannot have multiple simultaneous users. That allows it to detect the incorrectness of the count and set it back to one. This is only possible because Q&A keeps the file open at all operational times. Unfortunately for Q&A that also leaves the file "open" for some very severe kinds of unpreventable corruption due to power fluctuations, network outages and errors, and user mistakes. This is especially true on later versions of Windows, where open files are often cached in memory. A close operation flushes that cache and forces the memory to written to the disk file. But should the power go out before that has occurred, the changes that have been written to memory (not disk) are lost. In that Q&A uses a complicated scheme to optimize the position and relation of fields and records, this can lead to more loss than the data left behind in memory.

Sesame only opens the file to write out changes and then closes it again as soon as it is done. This means that Sesame files are less likely to be affected by power outages, network errors, or user errors. But it also means that we cannot clear the "sunlock flag" just because a file is closed (like Q&A does). That is why we provide the standalone utility "sunlock.exe" and the ability to unlock an application file from the administrative interface (local only - it will be client / server in 1.0.5).