There was a topic that covered this rigorously on someone's existing layout that popped this error on a suspected hidden object. I don't think this ever really got a "good" resolution.
If you're converting from FM3 to 12, that is highly suspect of conversion errors. Did the conversion log file after your 12 convert look suspicious at all? Any errors?
Were the errors in 11 as well? Or only since the conversion to 12?
If your file is not that complex, I'd suggest building a new file natively in 12, and importing the data from your new file. Sometimes a native rebuild is recommended to work out all the kinks. Certainly from a standpoint of converting such an old file up.
Thanks for your quick reply !
The conversion was done from FM 3 to FM11 and the problem already existed then. Earlier this year we migrated to FM12, where the problem continued. I don't recall if any errors were mentioned in the log files as we (about 2 years ago) converted over 600 files.
I guess the best is to start over, but the file is rather complex and this will take a lot of time.
600 files? that's pretty crazy. But if the error was there in 11 before migrating to 12, it does sound like something got corrupted in there during the former migration.
It might be time to re-think portions of the database. I'm sure there's hundreds of optimizations that can cut down on that for you. If you come up with a plan of action, you should be able to step up everything in smaller milestones.
It also sounds like this is a mission critical database, it might be wise to consult with an outside firm to come up with a migration plan that will firmly stabilize your database in v.12.
I realize that's a daunting task, but a 17+ year old database that large has got to be due for some optimization at this point. Hopefully your users/management will realize that and give you the buy-in you need as well.
A collegue has been looking into it as well. Apparently the problem lies mainly with the lay-out. The database does not appear to be corrupted. When he makes a new lay-out and uses the same fields everything seems to go fine and these fields can be copied. So the solution seems to be te remake all the corrupted lay-outs. Luckily not all the lay-outs are concerned). In the past one main lay-out has been copied and reused and it appears that this first lay-out and all its copies are corrupt.
What we dit experience during the migration from FM 11 to FM 12 is that a field on a lay-out sometimes gets corrupted. This happend with a file that had been created in FM 11. It was enought to remove the field and re-insert it.
As these old files and layouts are very complex it could be that only some of the fields are corrupt on this layout but it is easier to remake the layout than to start an investigation as to which fields are the culprits.
Thanks for the help !
remaking the layouts in filemaker 12 will probably also improve your screen load/refresh performance, so it's a good thing to do anyways.
Just curious, how did you know that a "a field on a lay-out sometimes gets corrupted". Was it reported in the Recover Log ? or did you just remove them one by one ?
Does the Recover Log show anything "changed" now ?
If you can, go back and run a Recover in FM 11, and check the Log
Before rebuilding, please pursue this with tech support. It is possible that Recover may need updating to address this particular problem
> but it is easier to remake the layout than to start an investigation as to which fields are the culprits.
We had two similar dropdown fiels on the same layout. One field was OK, but the second drop down list did not work. Someone from ClickWorks, who construct some of our FileMaker databases told us about this issue. It was in fact an underlying ID field (I did not know it was there) that was corrupt. By removing the field and then adding it again. The problem was fixed.
He noted that:
When he makes a new lay-out and uses the same fields everything seems to go fine and these fields can be copied.
So I don't think he discovered the issues via a log. Since he also noted "600 files", that's a tall order to run recovery on. It sounds like they never combined into a flat file when .fp7 came out.
I would also encourage to rigellee to run a check as well to identify any major issues before migrating to 12, but I am unsure if they've already started the move.
And not to say they don't already, but PLEASE make sure to have a current backup copy before you try and start recovery on a solution with 600 files.
No, the migration from FM 3 to 11 has been done 2 years ago. The log files have nog been saved. These files have been used since then, but since nothing had been done to the layouts this problem has stayed undetected. The migration from FM11 to FM 12 dates from February.