Do you commit your ghost records?
Yes. If you search for it, it is there. If you search for all records, it is not. Very strange.
a: 67 Cheval Place
t: 0207 731 4272
d: 0203 747 9520
w: www.kht.co.uk <http://www.kht.co.uk/>
f see our facebook page <http://www.facebook.com/pages/Kensington-Home-Technology/122963661112491>
This message is sent in confidence and for the attention of the addressee only. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. If you contact us by e-mail, we will store your name and address to facilitate communications. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.
Please consider the environment before you print
Then give us a snapshot of your relationship and field info for fields involved in that relationship
Sounds like it could be a corrupted index. What happens if you execute an SQL query for the IDs of every record in that table?
It might (might!) be something you can fix by explicitly turning off indexing on every field in that table, committing the schema changes, then setting indexing to auto and committing again. But I'd be searching for a known-good backup.
A faster alternative to turning off indexing one field at a time if you want to rebuild all indexes:
Tale a copy of your off the server if it's hosted from a server. Launch FileMaker without opening the file.
Select Recover from the file menu and select your file as the file to recover. But use Advanced Recover options with the following options selected:
Copy File Blocks As Is
Rebuild Indexes Now
The file thus produced should be identical to the original except that all field indexes have been rebuilt.
I trust you are working in List View, and not in a Portal
if you Show All, and a Record is missing, then it is not an Index problem
FileMaker has lost track of your internal record ID's.
To fix, Import all records into a Clone of the file
> When I do Find All, the records skip from 31 to 33. Record 32 only exists if you search for it directly
Anybody else see the demo of 360Deploy at DEVCON?
Maybe there are other products that do the same, but it's occurred to me before this that it might offer a more painless way to fix some of these issues as you could use it this way:
Pull a back up that doesn't have the issue to another machine.
Run 360Deploy (or similar tool) to put it up on the server in place of your file with the problem and with the data from the current copy in place of the older data found in the back up. (The tool handles the file copies, data imports and even file renaming with the copy on the server copied to an archive location.)
Wouldn't even need to start with a clone, but presumably that would work too.
I am doing show all and the record is not there. If I do a find for the record itself, it is.
It seems you are right, Filemaker has lost track.
I first noticed this when I created a new record via a portal. I clicked on the record to go to the related via and something else showed up. The record was completely invisible.
I have do this same exercise again and it works, so my relationships are OK.
Thank you anyway for you help. Not sure what I can do about this. I have around 60 tables each with dozens of fields. Exporting the who database and reimporting would be a total nightmare. I (unwisely) do my development on the live system as it is too complex to migrate the data. I have been developing the current solution for around 6 years.
if you're in a current version, you could try the new "truncate table" script step, then re-import that one table
that might work
> I have around 60 tables each with dozens of fields. Exporting the who database and reimporting would be a total nightmare
You might also grab a back up copy, recover it and test it to see if this fixes things. If so, try rebuilding indexes as I've described via recover and see if it works. It's a cheap fix if it works.