Mark,

In response to the issue I raised a couple days ago about losing a connection the the server over the internet when idle.

I do think the problem was mostlyrelated to the bug that Erika mentioned and will be fixed in 1.0.4. Last week, when I was "kicked" from the server because some "broadcast" message to the users from Designer(?), the server thought I was still connected and would not let me re-connect.

I tested last night by connecting to my office server and leaving a record visible on my screen at home. This morning, I was indeed disconnected from the server as I could not advance to the next record. If I closed the form, I could not open any others. (They appeared to open, but only showed a gray screen.) I had to exit Runtime and re-connect to the server, then all was well. This may be related to my ISP. I don't think its a big problem.

After the 1.0.4 fix, we should be in good shape.

Thanks again for all the help and support. Sesame is developing into something fantastic.

Steve

Steve,

I can certainly understand why one would need to run Sesame Runtime client/server through the internet. But are there any advantages running SDesigner client/server? Why not download the the application files you want to redesign, work on them locally and standalone, and then upload the result?

Otherwise:
There are only a few places in SDesigner that actually contact the server - so you may need to run a pinger to retain your connection. Saving your work often will also keep the connection alive.

Sesame, unlike (for instance) a web browser, does not connect and disconnect with every operation - reconnecting is too slow. For Sesame Runtime, this is probably not too much of burden in that it regularly talks to the server. But for SDesigner, where most of the the work is performed on the client and sent to the server in batches, an unreliable connection is going to be trouble.

Client/Server operation in SDesigner was added as a convenience to make it easy to make small quick changes without having to move files through the net. But, since only one designer at a time can work on any one application, there is only small benefit in using SDesigner in a "shared" medium like client/server.

If you absolutely *must* design client/server, then set up a different server on different ports and save often. By setting up a different server, you will bypass the "reset bug" discussed earlier (fixed in 1.0.4) and so you can save without upsetting other connected to the "runtime server".

Quote:


A powerful server will help with searching and sorting (etc...) but will not help with program speed or user interface speed. SBasic runs on the client (except retrieve spec programming), as does the user interface (of course).

Quote:


I take it that the server is a Windows based server? That does limit the options. If it is a file server, can you connect using file sharing to transfer the file through VPN or other tunneling protocol? If not, can you tranfer files to your laptop while you are at work and simply carry them home. If you have security concerns with ftp, can you set it up the same you are setting up Sesame - so others cannot access the ports? On Unix you can set up IP-chaining to disallow access to ftp except on qualified IP addresses.

Having Sesame perform a "Save As" to a local drive would be a security breach on our part without at least Administrator level access.

Quote:


No. All file operations other than exporting programming (as ASCII), HTML forms, and SBasic file I/O are performed on the server. This stops non-qualified users from generating materials on a box on which they control the security settings.