Depending on the context is either means that the file is not there or that you do not have permission to open the file.

"Cannot open" is actually fairly rare. In what context are you seeing the error message? Could you give us the full error message text?

Spanitz,

I'm going to suggest again that you contact Tech Support and let them help untangle your client-server configuration. Almost every question you ask is indicating to me that you are not always connecting to what you think you are, and that you may be rebooting the server with applications open. That this is happening on "all of your files" and some of your earlier questions indicating some confusion about how client-server is meant to work in Sesame (as opposed to Q&A) is pointing at a configuration issue that Tech Support can likely help you to sort out.

Troubleshooting network configuration is quite difficult in this environment, since we cannot really see what is going on. On the telephone, you can interact with Tech Support in real time and they may be able to help spot the problem.

Quote:


Are you still running Sesame as a service?

Quote:


No.  We fixed that today.  Sesame is running as normal at the Server.  The running as a service thing wasn't my idea, either.

Is there any better-than-not methods to import/export the data into a new (built-in-Sesame) shell?  In other words, I would build a new shell, export from the suspected damaged Sesame files, then import into the shell.  Is this just asking for trouble?

They have almost 20 years worth of data they still want access to...

Now, keep in mind that our server setup might be, errrr, screwed...  <grin>

What I saw happening is that when Sesame ran into trouble, the service froze requiring a complete shut-down of the server and a reboot.

When it is now running as a normal application (the "Sesame server mode" on the actual server), when it runs into trouble it just shuts itself down.  We notice nobody can access, then walk over and restart the Sesame server mode.  I can see the benefit of this setup.  Now to get to the point of no shut downs!   

(Yes, once we bring Sesame back up in server mode, we also sign on as admin first and unlock the files and make sure the client-mode copy of Sesame on the server can open the files first.)


In case these files are hosed from the incorrect stopping of the service (who knows how many times) is there an way to salvage the data, or do we have to roll back to the questionable from-Q&A data?

Quote:


The real problem is that it can mask and obscure any difficulties that may be occuring. To run Sesame server as a service, the "-daemon" flag must be specified (to prevent Sesame from trying to establish a server user interface). Without a user interface, the only diagnostics on the health of the server is the log. Additionally, if there has been a problem, and Sesame is started as a service, it will restart everytime you restart the OS, giving you no chance to work things out before it starts up again.

We worked very hard to make sure that little to nothing about Sesame is platform specific or tainted by outside dependencies. Wrapping Sesame in an OS's "service mechanism" involves Sesame in the issues that may be lingering in the OS's network connection model. The only benefit is that Sesame server will start when the OS starts. But even that is risky, in that there is no assurance that the OS software that is required for reliable operation has been initialized before any particular program needs it.

So would I recommend that you set up Sesame as a service: only if you are already very stable in your network setup, you have a strong understanding of services and daemons, you are running on a secured and stable platform (prefer Linux over anything from Microsoft), and you have the actual requirement to start Sesame server immediately on boot.

Quote:


Yes. You would not have to leave a system logged in if you ran Sesame server as a Win32 service. Nor would you have to log in to start the server. So in both those cases there is an advantage.

You must be careful to make sure that the services on which Sesame relies are already running before Sesame starts as service. Dependency checking for services in WIn32 is done using registry enties. They are not set up by default. In the case of Sesame, TCP/IP services must be up and running before Sesame is started.

Additionally, it is critically important that Sesame server be properly shutdown before the service representing it is stopped. Win32 OSs simply kill the process (using "TerminateProcess") giving it no notification or warning. That will cause the server to drop suddenly, even if it is mid-operation.

Worse, because of "limitations" in WinNT, a service can either have "interaction with the desktop" or "interact with the network" but not both. Sesame in normal mode, does both. Using "-daemon" flag may help with this, but I can't be sure.

On top of all of that, Win32 sends services messages that are not processed by normal tasks when the user logs off. The default method invoked for this message is to suddenly terminate the process. Sesame does not directly handle any Windows messages, and I would hate to add non-portable code to handle this unique windows-ism.

As far as security goes, Sesame is based on TCP/IP - a well known and well documented (older than DOS or Q&A) standard, on which security layers can be added through standard and documented means. I don't know if Win32 "services", being completely proprietary, respect and adapt to TCP/IP security measures. I can't even say for sure if Win32 OSs aren't stopping and restarting the processes they represent in somewhat arbitrary ways.