Every time I update either a procedure or a form or add a field to a shared database, I seem to break the database.
When the newly updated database is downloaded to a workstation, I either get the dreaded "Runtime Call( failed" error or I get one of the following that appear on the server itself (yes, the server – not the client):
"Field or variable <some name> does not exist"
or
"Window not found"
I have several questions about this, in order of severity at this time:
How do I revert to the previous generation/version of the database? (This is needed so my client’s work/business is not disrupted)
How do I debug/troubleshoot these kinds of issues?
What’s a “foolproof” workflow that allows me to update databases without ending up with these issues?
Note: before I uploaded the database, it was working as expected on my local machine.
Answering by the number and referring to the client business as the customer for clarity over client computers:
If you have remote access or another way to get onto the customer’s server, make a backup of the Public Databases folder before doing updates and a backup of the client files. Restoration os relatively easy then.
You didn’t say when the errors occur…during the file download? When the file is launched? Have certain procedures been run on the cleint machine that have set variables or expect windows to be open that aren’t?
If you can run a connected client yourself, standard debugging processes are best - or a series of messages within a procedure to identify how far it’s gotten without erring.
Run a copy of the file on your machine as a shared file. You can run Enterprise yourself in Demo mode for two hours before you have to renew the demo for another two hours. If you have a second computer make that your server. Otherwise you can run client and server on the same machine. The clone feature in sharing works though it occasionally gets confusing or confused, I’ve never been sure which. I tend to run two folders of a customer’s shared files; one for my own testing of the whole experience. Usually I convert a copy of the customer’s file(s) to single user, then share it on my server. For testing your errors, it would be better to mirror any changes and go through the new generation process yourself to find the issue.
I was able to restore the previously good database from Time Machine. It just runs silently and inconspicuously in the background and I often forget about its amazing restorative powers! LOL.
Regarding my database, the changes I had made – aside from adding a couple fields – was all done on a “current generation” of the database and had been extensively used/tested for a couple weeks without issues. I then wanted to push my new procedures along with the additional fields to the server, and then everything broke. Kinda puzzles me.
I do appreciate your comments and insights and like the idea of running a “backup/test” enterprise server to try things on.
I have another question, related to your suggestion:
Give server A running on a “remote” Mac and server B running on my “local” Mac:
What’s an easy way to:
Un-share a DB from server A Re-share that DB to server B
I tried just using the Database Sharing Options wizard, and while both servers show up in the Choose the server on which this database will be hosted popup, but even after un-sharing a DB, I cannot change the selection within that popup – they both show up “grayed out” and set to server A.
Sharing and unsharing is clumsy but it can be made to work. It’s better to either run two sets with one as the customer’s shared database(s) and one as your own. Make changes in yours as you work and test, then copy those changes to the customer’s set and update via New Generation. It does require that you stay alert to changes in order to carry them over correctly. I use copious change notes in a “.versions” procedure. I also copy entire procedures to a text file then paste to replace the entire procedure in the receiving file. That avoids needing to search out a line or two, or retyping field and variable names, hoping to make no errors or omissions.
Once in a while I replace my copies with the customer’s just to be sure I’m running the very same thing. That’s a matter of copying a file, dropping into the “work” folder, then unsharing it form the customer’s server and resharing it to mine.
Another way, and the way Enterprise is designed to handle it, is to create a clone for use on your in-house server. I’ve used that with good results too, but whether it was user error or software error, I’ve often had the software not recognizing one server or the other. See the Clone menu in Database Sharing Options. It’s appealing.
Once again, you’ve given some great insights. Thanks!
The “Clone” option looks very appealing.
However, I’m getting the sense that it might not be as robust or predictable (deterministic) in execution, from your experience. Would that be a fair assessment?
Aside: I’m noticing that if I run an Enterprise server on the same host that runs (client) Panorama and I double-click on a database, it often (always?) activates the Enterprise server rather than the (client) Panorama app. Is that an anomaly on my host? Or does that happen elsewhere, as well?
The clones have worked well - at times. Sooner or later it seems that the connection to one or another server breaks down as far as Database Sharing Options is concerned. I’ve been through it a couple of times and never pursued it adequately to know whether it was me or Panorama to blame.
As far as one machine as client and server is concerned, since a few OSX’s ago, if Enterprise is running, files opened from the desktop open in Enterprise. It’s necessary to either drag them to Panorama or open from within Panorama to use both on a the same machine.
That error comes up if you’ve disconnected from a server without closing the file first. The database cannot sign off with Enterprise so the session is noted as not open. It doesn’t have any effect on the data, just the ability for it to save any changes made since the connection was dropped.
There seem to be some issues having more than one available server at a time. Pano gets confused and will indicate no server can be found. So, I manually set which servers are available … which is a bit tedious.
