Some possibilities to check for:
Do you have a script that uses Go To Related Record? If so, check the red text in the following thread and see if any of those issues apply:
Do you have any layout based script triggers?
If so, you may have a script trigger such as "on Layout Load" that is doing its thing when Go To Layout in another script navigates to this layout. You may need to use FMP advanced's Script Debugger to figure this one out.
Other script steps that can do this:
Import Records (using the update matching records option)
Replace Field Contents
Also, if you have a corrupted field index, a script that finds a group of records and then modifies them may fail to pull up the correct group of records.
I don't have any scripts at all, actually. is there anything else that this could be?
The data replacement seems to happen when I run the sort function--sorting by date. But it's also possible that that's just when I notice it.
Is the field from a related table?
Are you sure that you ( or other users ) are really in Find Mode when you do a search ?
( if they think they are in Find mode, but really they are in Browse Mode, they may modify data )
do you have any import ?
That's a really good point. It seems so obvious that most people wouldn't consider it, but it happened to me a year ago and it changed a large amount of data which fortunately was backed up. It's also a strong argument to setting the field behavior to NOT allow entry in Browse mode unless absolutely necessary, but allowing field entry in Find mode.
Could a user accidently preformed a replace on that field. (cntl+ =) It is far too easy to do and many users will hit ok before they read a dialog.
I have taken to using custom menus just so I could prevent a few users from being able to hit a Cntl+ = (replace command) although it rarely happens that a user hits it, it can cause this (Is the shortcut for replacing field contents and is right next to Cntl+ - which is the shortcut for the current date). Custom menu's can also help you prevent users from hitting Cntl+ E (delete record) and Cntl+ D (duplicate record) both of which have caused problems for me in the past. (sometimes you need to give them the privilege to do it but do not want it to be that easy)
I have a similar issue. A couple of our records, for no apparent reason, have all the data replaced by question marks. Every field contains nothing more than a "?". When you search for the record and type in the name, it pulls the record, but displays only question marks. Furthermore, it will not allow any of the data to be changed. It also will not allow the record to be deleted. We have a consultant, but he is at a loss to explain what is happening.
We are running 10 on a Mac server with 9 people having access. Any help would be appreciated.
a ? indicates that the field cannot correctly display the data. The most common cause is either division by zero in a calculation field or a number field that is too narrow to display all the digits.
It doesn't sound like this is the case in your situation (you consultant would have figured that out easily by clicking in the field).
I suggest recovering the file to see if that fixes the problem. If it does, your file is probably damaged. Replace it with an undamaged back up copy, importing data from the recovered file as needed to update the back up.
uestin mark :
It's an index issue, you should rebuild all index by tedously unindex every field and put indexing back on
or maybe by the repar tool but it will say yiu shoukdn't use the db anymore
I recovered the file, and it seemed to work. It did delete the one record that was filled with ?, but I can re-enter that record. Any idea what may have caused this? I'm also worried about using the recovered file as Filemaker recommends against this, but I don't like damaged records!
Thanks for your help
Thank you for your post.
It's difficult to determine what caused the corruption, and it may not be anything you did directly.
The Recover command will try its best to produce a good working file from a damaged file. Most of the time, the recovered file is fine. However, during the recovery process, an object may be interpreted as not being corrupt but actually is corrupt. It is not an absolute solution. That is why the recommendation of reverting to a previous working copy.
If you have a previous working copy, then use it, and import the records from the recovered file so all of your data is up-to-date. If you don't have a previous working copy, then work with the recovered file. However, I would urge you to recreate a new file and import the data just to be safe.
Well, I looked through the recovery log and there wasn't much data that appeared to have been dropped, so I used the recovered file. This is actually the second time we have had a record become corrupted, seemingly just out of the blue.
I would like to say the response here has been great, and I really appreciate the help.