> There's no such thing as a "single user database" as opposed to a "multi-user database". Why do all this chopping about with new instances of the application? While it's true that you can shut down the embedded connection by terminating your application, it's only one way to shut down the embedded connection. According to your experience, it's the wrong way.
>
> In the embedded library you have an embedded client that is perfectly capable of connecting to remote servers. There's no need to shut down your application and restart it in order to connect to a remote server. The same client can be connected to the local database via the embedded server and to other servers (via TCP/IP) simultaneously. You can detach from the local database any time you want to: the server doesn't go away. When you want to reconnect, it will be there, ready to roll. Same goes for connecting - disconnecting - reconnecting to any of the dbs on remote servers.
Thanks Helen:
The app isn't shutting down to close the connection, it's shutting down, and restarting, to rebuild a massive amount of data in a tree, and some other structures, it's keeping in memroy.
I think you are right though. The monkey motion involved in the shut down and restart is having side effects I didn't anticipate. The application needs to carefully purge and re-build the memory structures it need when the user changes databases. Without shutting down.
As often happens Helen, you aren't telling me what I want to hear, you're telling me what I need to hear.
As I've told you so many times in the past, I appreciate your assistance.