AnsweredAssumed Answered

FM11 Save As Copy: an important bug?

Question asked by ralvy on May 3, 2010
Latest reply on Aug 24, 2010 by ralvy


FM11 Save As Copy: an important bug?


Recently, while testing a release of a FM runtime solution with FMDiff, FMDiff reported I had 5 orphaned blocks. Though Recover found "no problems" with the same file, looking into its recover log I see entries at the end like this:

"Page 853 marked free but not in free list"

What I have found, in extensive nervous testing of many previous backup copies of this solution in the last 24 hours, is that I can reliably do this:

1. Load a version of the file that is clean with with FM10 and do a Save Copy (not compacted).

2. Test the copy made in step 1 with FMDiff and find no errors.

3. Load the same file with FM11 and do a Save Copy (not compacted).

4. Test the copy made in step 3 with FMDiff and find the orphaned blocks.

This is reliably reproducible. What is also reproducible is compacting the file results in FMDiff finding no errors. But saving the new compacted copy as a non-compacted copy with FM11 will produce the errors in the new copy. Again, FM10 doesn't do this.

Anyone know if FM11 "Save as Copy" works differently than FM10's version of that?"

Before reporting this to FMI, I've been trying to create a small solution that will reproduce this. I was able to get that solution to produce an orphaned block on a File Save (with FM11) only once, but further testing isn't producing the error. So I don't have the pattern yet.

More about this particular file. It's part of a data separation solution. The problem file is the UI file for that solution. It consists only of 3 utility tables. 2 of the tables have only a single record each on startup, and the third is empty on startup. On startup, the existing 2 records are deleted and then recreated. No file in the solution has FM11-specific features.



<!--   ~-|**|PrettyHtmlStart|**|-~   -->