Robert’s advice was all excellent – in the past. Certainly it is excellent advice for Panorama 6.
Panorama X uses Apple’s standard document handling code for loading and saving files. Apple’s documentation for this indicates that this code will work correctly even if you move a file in the Finder – while the file is open. Before today, I had never tried that. Oddly, I had been thinking about this just a day or two ago. So, just now I tried it. Lo and behold, it works. I opened a database, then went to the Finder and moved it to the desktop folder. Made changes to the database and saved it, no problem, the file on the desktop changed. Command-clicked on the icon in the window and it showed that the file was on the desktop.
I even tried using the dbinfo(“folder”,…) function, and it correctly returned new path for the file in the desktop. So, in Panorama X you can move a file even when it is open, and Panorama X will immediately recognize that this has happened and everything will just continue to work. I believe this should work for any modern NSDocument based application.
That still leaves the mystery of why Michael Kellock is running into a problem saving his database. Unfortunately, I have no idea why that is. A downside of using Apple’s code is that when there is an error generated by Apple’s code, I have no idea what the problem is or how to fix it. And this error is coming from Apple’s code. You might look in the Console and see if any additional information is output there when this error occurs. Maybe there is some sort of permission problem?
Since apparently you can open the database, one thing I would recommend would be to save this database as a blueprint – use File>Export>Blueprint. This will save the structure of the file, including all forms and procedures, as a collection of text files in a package. The blueprint file is saved in the same folder as the database. You can then create a brand new database with the same structure by using File>New>New Database from Blueprint. The blueprint doesn’t include the data, so if you need that, you’ll have to export it separately as a text file and re-import it after creating the new file from the blueprint. The end result will be a brand new file with no connection to the original, but all the same structure.
Geek note: Blueprint files work great with git for source control. I use that with all the coding in Panorama X to keep track of what has changed. Whenever I’ve completed significant work I export a blueprint and then commit those changes to the git repo. I realize what I just said will make no sense to most of you, you can just ignore it. But someone in the future is going to read this and say “hey – that’s fantastic.” Here’s an example of how a change I made in _DatabaseLib yesterday appears in the git repo (I’m using an app called SourceTree to work with the repo). As you can see, I can easily see exactly what was changed and when.
Among other things, I use this information to compile the release notes that are included with each release. I also use it if something goes wrong to see what exactly was changed.