When something like this occurs restarting the machine and relaunching FM could help.
Since both problems went away and have not appeared in the last two days, it would appear that a re-boot would not help.
Heya Jim! Nice to see you at least virtually. : )
I can't speak to your exact issue, but have seen weird issues arise due to, we suspect, the network. Unfortunately there's not a real way to test for this and usually a re-boot of the server did seem to fix it. Unless you're able to replicate it in some manner I suspect you'l never really find out the cause. Helpful, aren't I? Hahaha.
recovering a file and sharing it is something I'd steer away from.
I'd rather open the file locally, save a compressed copy and share that one.
(of course an additional, separate recovery - watching for errors - is a good move, might give some clues and eventually lead to saving a clone and importing data into it)
BTW, do you have any WiFi users ?
Nick! How are you at there in the land of weird?
Yes it does point to the network for some odd reason but I have found new information that showed another report that makes use of the same information was also displaying weird numbers. This suggests that the data was actually changed. However, those numbers are correct today. (Large record set so no way someone corrected them).
Are you going to DevCon?
Yes there are wifi users but the main users that actually saw the problems are hard wired.
Aside: Though I understand best practices and at the risk of going down a rabbit hole on this thread, what good is recovery if you can't make use of the file?
Nope, but I'll pm you as I'll be in Denver in a few weeks.
A FM File is different from other files. A recovered FM File can be compared to a building which caught fire. You saved the people (= the data), you "saved" the building because you've put out the fire, but the place is not nice to live in anymore. You CAN go on with the recovered document but it might be safer to profit from this temporary opportunity of separating the data from the engine and feed the recovered data to a safe, potentially flawless engine, best coming from a backup etc.
What really counts is data, produced over years. If recovery saves that, then you can be happy.
Another rare problem could be a memory issue that only occurs with high memory usage and/or over heating. Pulling and reseating it could cure the problem. (very rare now days, used to be common problem with some motherboards)
btw. There is a feature request for a 'recover' that really recovers a solution as a whole thing. I just wondered if there is a request after reading this postings here - filter for 'recover' in product ideas..
I should be possible - if one opens a .fp7 file in FM15, it will convert all the stuff, why not do this rigth after the first recover step?
It would pay to run Recover, just to check the Recover Log for "problems" ( then trash the recovered copy )
I recently had a report fail, because it was generated by a script, over a WAN. The script exported, then imported, data, which failed with the slow connection. Look for possible timing issues
It is very odd that the problem comes, and goes. If you had a broken field index, or a scrambled record index, it should fail each time. Is it possible it only fails when certain records are included in the report ?
Use a script trigger, to log any date changes, to see if it could be user error
Also, in this post, it was apparently Bonjour that caused the report problem:
> I understand that a damaged document could explain this and will recover the file when down time allows
Recover does build a new file
However, it is impossible to say a file is "OK". You can only say a file had no "problems"
Even when converting to a new format, FileMaker says:
"FileMaker does a very good job of converting databases, even those with some structural corruption. The resultant FileMaker files should be corruption free however as with most issues of file corruption, the conversion engine may not satisfactorily convert unhealthy files"
Either way, we should have a proper Verification Utility. Using the Recover Log as a verification tool is not for the faint-hearted
> if one opens a .fp7 file in FM15, it will convert all the stuff, why not do this rigth after the first recover step ?
I recovered a copy of the file last night and received a clean bill of health. No problems were found. So, to the degree that we can trust recover, we can rule out a damaged document.