Caution to developers

[K1200]

I just want to share details about a major problem I encountered in upgrading my runtime solution from 8.5 to 10.0

My application is based on the separation model that I first implemented under FMP 8.0. I have successfully (in the past) conducted smooth upgrades to installed systems by simply setting the database.fp7 aside, upgrading the entire contents of FMP and application directories -- and then copying the database.fp7 back onto the directory to restore the customer’s information into the application. It always worked without a hiccup. I came to believe this was the foundation principle behind and advantage of the separation model.

When I began upgrading installed systems to FMP 10, it no longer worked. My application installs normally -- and runs fine with a largely-empty default database file. But in each case when I substitute the original database.fp7 file, I get the following message/prompt:

This file has been improperly closed, checking for consistency ...

Its progress bar gets about half way and then it’s interrupted by this prompt:

Database.fp7 is currently in use and could not be opened. If this file is shared, you can use the Open Remote command to open the file on the network. (If you've opened the file before, check the Open Recent menu.) [OK]

Clicking OK brings up a selection dialog -- I suppose to select a different file. But the correct file is already being processed, of course. Clicking Cancel for the selection results in:

Application.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

Inconvenience is an understatement. Upon repeated attempts to start the application, the message/failure sequence never varied. My solution was to bring the database.fp7 back to my development computer and open it directly in FMP. It opened just fine. So I closed it and transported it back to the field computer. The field application then opened fine as well.

My conclusion: In FMP 10 there’s a flaw in the runtime’s Open File processing when opening a data file written by a prior FMP version -- a flaw that doesn’t exist with “normal” Open File processing. So it will only affect runtime solutions that use the separation model.

This is discouraging. I’m faced with taking a laptop to individual customer sites and “converting” their database.fp7 files. I guess I should be glad that I’m only working with several sites and not several hundred. Some others may not fare so well.

Obviously, I’d like to hear of some great workaround -- but I’m not holding my breath. Maybe this File Open failure is due to some obscure data case that no one would have thought to test. It would be comforting to hear that someone else has encountered it.

This is one of about a dozen “trip wires” that I’ve encountered in FMP 10. Judging from the FMP 10 list of new features, FileMaker is paying more attention to their “12 million” installed base and less to a few hundred developers. At least that's how they've made me feel.

[bcooney]

Wow, you're running XP SP 3?

[K1200]

bcooney, my hat is off to you. That was an excellent long-distance analysis. As it turned out, neither of the two computers that experienced the “improperly closed” database had been upgraded to SP3. When the same runtime was installed on a third computer running SP3, it worked perfectly. Upgrading the first two computers with SP3 resulted in them working as well.

But there was more to learn from this episode.

Following the workaround where the “opened/closed” databases were able to be used under SP2, they apparently worked fine. It was an illusion. Within two days, one of them failed while stepping through existing records on a layout and then encountering a newly-added record. A popup stated that a database error was encountered and the application closed.

But content had been added that the user wanted to retain. The apparent solution was to again open and close the database on the FMP 10 development computer to “fix it”. It would not open. The popup message from FMP 10 suggested trying the Recover feature.

Recovery did work -- with a handful of problems reported. At then end, however, FileMaker gave directly contradictory recommendations. The end-of-process popup stated that the resulting file was safe to use. The log file, itself, stated it wasn’t. I’ve attached the relevant sections of the recovery log, plus the pop-up message for reference.

From things I've read, I tend to believe the dialog box represents FileMaker’s latest official position on recovered database files -- and that the message in the log file is one they simply forgot to update from earlier versions. We are going to run the recovered database and -- as they suggest -- watch it closely.

Having been at this a while, I certainly try to “think of everything”. But I simply missed considering the OS version possibility -- which points to the value of always having a preflight checklist.

RecoverySynopsis.txt

[bcooney]

I got lucky. Given I'm in the runtime business too, I thank you for the heads up.