Hi, I have this Record apearing in my solution that has all question marks in its fileds and does not delete for some reason, has anyone come across this?
see the screen-shot please.
Thank you all.
I have seen this problem a number of times...and I'm not happy about it.
In my case, I'm guessing it's a corrupt record caused by a loss of 3G connectivity while FMGO writes to a shared database. There is a wealth of information about corruption issues here: http://fileshoppe.com/recover.htm; you can search for additional info but this is the best summary I have found.
The suggested solution is (always) to reindex. I have tried reindexing...and much, much more; nothing has successfully recovered the data represented by "?".
If anyone else has a solution, I'd love to hear it.
Thanks for that pointer I will check it out…
I have just reindexed (turned off and on indexing on my key value) and now the problem seems to have gone.
Just hope it stays away as you said it’s a scary one, I will check out your link. Thanks for the reply.
If you suspect corruption and don't fix it completely then it WILL show up again.. probably at the worst possible time if Mr Murphy still rules.
Repairing the file itself is only part of the fix.. you have to figure out the root cause and implement fixes that will produce as close to a permanent fix as your situation warrants.
FYI complete repair means nothing short of complete rebuild of the file scratch or restore from a known perfect backup.
Their are many causes and if its connectivity issues perhaps you should check out the work by way smarter guys than me on transaction control in Filemaker. Todd Geist has done some great work in this realm and has probably ported his concepts to FM go by now.
Coherentkris is right:
But this should be avoided by always keeping a clean version of the latest version of the database - a development version - separate from the running version on the server.
Then, if, something should ever happen you can just export/import data into a copy of the newest version of the solution.
Thats why it is my std practice to follow a development itteration with clone and archive
Please see <http://fmdiff.com/fm/recordindex.html> for details and a possible cure.
Winfried Huslik wrote: Please see <http://fmdiff.com/fm/recordindex.html> for details and a possible cure. Winfried
Winfried Huslik wrote:
In the aricle it is recommended to export the record, delete the ghost version, then import back to your soloution.
In each case we I've had the misfortune to encounter these ghosts, the export will be blank, the "question mark record" can not be deleted and the only remaing alterantive has been to save a clone, import all data back to each table and go look for the messed up record in the backup jungle.
Anyone found a better way? Is this happening more since FileMaker 9/10/11, or is it just me?
All input appreciated!
Please note there are four kinds of indexes and each has (or has NOT) its specific method to repair it.
A "question mark record" as such does not exist and hence can neither be exported nor deleted.
You did not elaborate at what occasion these "question mark records" showed up with your file, but since you could solve the problem by reimporting into a clone you obviously had a damaged Value or Word index.
To answer your additional question: If it is just the Word index, switching indexing OFF, exit, then ON again may work. If this happens a lot to you, you may have a weak hard disk or network problems while having uncommitted related records.
Check out the new FMDiff 2.0 to compare two FileMaker files and test for file corruption at <http://www.fmdiff.com
Hi all, Thanks for all those insights, I did re-import the data and and reset my index fields so now that record does not show anymore, anyway I am glad to have gotten all that info. Thank you all.
Your not done yet.. You have fixed the immediate issue with the file but the error can and probably will resurface. The prudent next step is to try and nail down a root cause for the corruption and implement a corrective action that permanently mitigates the problem.
My two cents.
I am aware of it, so I will be on the lookout for where my logic goes wrong I suspect it has something to do with my import meachannism I import a template data records to be updated for the (next) current roster fortnight, anyway I will be looking for it, still i learned a lot here thanks again.
Retrieving data ...