FMP11 Recover and Grouped Objects on layouts

[brian rich]

A recent FMS Server outage left us with a number of databases which were reported as damaged when we ran the Recover option on them. When we went to look at our 'clean' versions, several of these databases were also reported as damaged by the Recovery option, something which didn't happen when we ran them through the recovery process with an FMP8 Client. Aware that the FMP11 recovery process was supposedly 'improved', we looked at the detail in the recovery.log files produced.

In many cases, the recovery process was reporting that grouped objects on certain layouts had been rebuilt like this.

2012-08-15 02:10:21.060 +0100 Day file.fp7 0 Recovering: layout 'QUOTATION (Related layout)' (119)

2012-08-15 02:10:21.063 +0100 Day file.fp7 8475 Rebuilt group with 4 object(s)

2012-08-15 02:10:21.064 +0100 Day file.fp7 8475 Rebuilt group with 4 object(s)

2012-08-15 02:10:21.064 +0100 Day file.fp7 8475 Rebuilt group with 4 object(s)

2012-08-15 02:10:21.066 +0100 Day file.fp7 8487 Reset table view

2012-08-15 02:10:21.082 +0100 Day file.fp7 8476 This item changed

....

2012-08-15 02:10:22.292 +0100 Day file.fp7 8495 WARNING: problems were detected while recovering the database. The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file

Curious, we examined the layouts which were showing the error, looking for sets of grouped objects that might be generating the problem. In most cases objects were being grouped simply to help with layout design. As an experiment, we ungrouped such items and ran the recover process again. Recover now reported the database as safe to use!

Concerned not to be caught in the same position again, we built a Clone Check database which runs nightly on our Filemaker Robot Client. The Robot grabs copies of the backup clones produced nightly by the server, runs a local recovery on each database and analyses the recovery log, looking for errors. It stores the state from that analysis and compares it with the state of the previous analysis, and emails the administrator with the results - so we know which databases have recovery issues requiring resolution and more importantly when a database goes 'bad'.

Guess what! Following some changes to a layout in one of our production databases which involved adding a graphic and a text label, grouping these as a button, and adjusting some of the adjacent elements, the Clone Checker reported a status change to 8495 WARNING. The error was on the layout where we made those changes. Ungrouping three graphic elements which consisted of a pair of FMP lines grouped together cured the error. Those elements were not new, they existed prior to the change and didn't produce an error. A copy of the panel on a development layout where it had been rebuilt doesn't report as an error. Bizarre!

Two questions:

Why should such a simple change to a layout corrupt a database, especially since it appears reversible by the simple expedient of ungrouping objects?

How should we treat a database that has been 'repaired' in this way - can it be used safely going forward?

TIA

Brian

[K1200]

I encountered these group-related errors for years — in FM10 and FM11 — and had taken to ignoring them. Months ago, I found this more-detailed analysis that confirmed what I had surmised: http://fmdiff.com/fm...s19rm5fhmqgtlv1

I can add that once my files were converted to FM12, the 8475-related errors disappeared. It was one of the first things I checked. Since there were no changes to the files other that the conversion, I suspect that it was FM11 validation software that was repaired, not the files.

[brian rich]

Thanks for your comments and the reference to the FMDiff website.

When your boss has panic attacks seeing that the backup files are apparently corrupt, he doesn't get much happier when you tell him the solution is to ungroup a set of layout objects and then regroup them again.

Just hope he decides to make the move to FMP12 sooner rathe than later!

Brian