Well I am no expert by any means, but if you fill a clean bucket with dirty water, it too will be dirty. I was told by a developer friend of mine to back up the corrupt file then run a recover file. Then save as clone and import all tables from backup. You will still need to go through file to fix any lost scripts, layouts ect. but will be better than the original corrupt file. (As I said I’m no expert, so I can take criticisms on my posting)
Does anyone know enough about under-the-hood workings of the FP7-to-TMP12 conversion process to know if the resulting file will be free of corruption?
Would it be sufficient to do a conversion then run the recovery test on the newly converted file?
1 of 1 people found this helpful
With each version conversion, FileMaker has always stated that "The resultant FileMaker files should be corruption free", but there are no guarantees
It is worth a try. It also helps if you know what is "corrupt", and it's repeatable, so you can test it yourself
You can read more here:
> Does anyone know enough about under-the-hood workings of the FP7-to-TMP12 conversion process to know if the resulting file will be free of corruption?
1 of 1 people found this helpful
I have a file that has reported corruption (a table long since deleted). When I ran conversion, the same issue still showed when I ran a recover.
Thanks for the input. I have been using FileMaker since the unnumbered version 1, and have never had to do a "rebuild" to deal with corruption in that 20-some years, but I have a potential client with poor FM hygene, and was hoping that the move to FMP12 format would provide a fix. Here's what I've gleaned so far from the response.
- Chefportal and Greg recommended essentially the FMI Knowledge Base process for recovery within the FM7 file format (KB Answer ID 1580). Chefportal's concern re "dirty water" depends on what is actually being done behind the scenes by the conversion and what type of corruption exists, but we have no FMI input yet.
- Malcolm suggested what I would consider a nice clean test, but whether or not Recovery will always report "hidden" corruption seems problematic. I guess that's why we call it "hidden."
- Greg also quoted from the FM8 Migration white paper that a file newly converted to FP7 should be free from corruption. I an not clear on the fine points of the meaning of the word "should" in this context, but I wish it were reliable as in "will be free from corruption" rather than "we sure hope so".
- Tom provided the clinker -- an actual case where the conversion from FP7 to FMP12 failed to remove some corruption. So we know that FP7-to-FMP12 conversion alone cannot be relied on to remove all file corruption.
So, in the absence of additional feedback from within the engineering team, it seems that the safest approach I can recommend to a client (short a new file built from the ground up) is:
- Follow the lengthy process recommended in Knowledge Base article 1580
- Convert the resulting file from FP7 to FMP12
- Run FMP12 Recovery on the new file.
- If anything appears in the Recovery report, repeat step 1, above, on the FMP12 file, per article 1580.
- Then hope for the best.
I would still love to hear from anyone who worked on the FMP12 Conversion programming, but I fear that Tom's clinker won't make me feel safe without jumping through all the hoops anyway.
Thank you all,
just out of curiosity, what "corruption" do they see ? is it in the current Recover Log ?
> I have a potential client whose FP7 file running on FMServer10 was known to contain corruption more than a year before I was put in touch with them, and they have no clean backups
Stephen may have started before zero was invented,
The conversion of 7-12 does remove 'file' corruption. However, there are a couple of things that cannot be 'fixed' as they are not part of the file, they are data.
1. Images imported or pasted into the layout can be corrupted.
2. Bound objects sometimes show invalid grouped characteristics and return a 'false positive'. Ungrouping the items before recovery corrects the issue.
3. Invalid characters in the data. Copy and past from Word processors and the internet can introduce characters which cannot be typed into a field and are therefore "suspect". Doesn't mean the file structure is corrupted, it means the data is corrupted.
I suggest you also check Winfried Huslik's site. He has studied the FMP file structure more than anyone else I know.
There is nothing in the conversion process which is designed to fix corruption, per se. In fact, I have seen one or two cases where pre-existing file corruption actually prevented the conversion process from completing successfully, even though the file was openable in FMP11.
Because conversion creates a new file (and, hence, new file index blocks), I would expect it to fix errors reported in a Consistency Check, but not a Recover.
My recommendation would be to perform a Recover operation on the PRE-converted (.fp7) file and carefully inspect the log file. Even if you end up converting the original, un-recovered file, the log file generated by the Recover command is extremely useful as a diagnostic tool. Begin at the end, by reading the summary at the end of the log file. If the log file reports no errors, attempt a conversion on the original file. Assuming it completes successfully (which I would expect it to), I would recommend following the same procedure (Recover, read log file) on the converted file just to cover all bases.
If errors are reported from the recovery of the pre-converted file you should attempt to address the corruption issue prior to converting. The best way to do that will depend on the number and nature of the errors. For instance, if there is a simple isolated error such as a corrupt layout object it is usually sufficient to merely delete the offending object. If there is widespread corruption the situation is obviously much more serious. You should search the log file for “ERROR,” “WARNING,”“modified,” “changed,”“dropped,” “damaged,” and “invalid.”
If you find erroors and want to post them back here (or email them to me) for comment, I'd be happy to look them over.
Hope this helps,
You and Greg suggested I check the form of the corruption that has been reported.
I am aware that some errors which get reported in the Recover process aren't real file corruption, and I intend to do my own recover testing as soon as the client releases a current copy of the file to me. At present I am working only from information provided by a previous consulting developer who found "corruption" reported in recover reports run a year ago, including on all of the backups they had. The client took no steps to deal with this because the file hasn't died on them.
I am being asked to propose a process for getting them back to a safe file. This thread was my hope for the proverbial quick fix before estimating costs for both file testing and possible slogging about with the process required if there's no simple fix.
More later, when I get a file to test myself...
And Thanks for the reminder of Winfried's site.
It sounds like my game plan should start with a Recover on a copy of the original file as an initial test and examination of that recover log for clues before moving on to the steps I outlined earlier.
The notes you provided on which types of issues to particularly watch for are useful, if/when the client decides to let me run my own tests (see my earlier note to ch0c0halic).
I will take you up on sending you info from the log if there is anything unexpected or worrisome.
Thanks again for your always useful insights,
per our brief discussion at DevCon, please publish a list of the errors Recover can recognize, with their "severity"
( or just a list of those errors with "low" severity )
this would help greatly !
> If errors are reported from the recovery of the pre-converted file you should attempt to address the corruption issue prior to converting
( cont'd )
It would also help if you could somehow get this into the Knowledge Base
If true ( and it probably is ), it is somewhat of a departure from FileMaker's previous position
If the conversion does not "drop invalid blocks", or "fix" them, that's fine. We can check after
I also was not able to find a "FileMaker 12" Migration document. FM 8 was the last I saw
> There is nothing in the conversion process which is designed to fix corruption, per se