OS? Win or Mac? FMP version? DB hosted how?
Error occurred when? Does a backup exhibit the same behavior?
Copied to your computer, does it exhibit? Any recent changes? Plugins installed?
Win 7, FMP v 12 and FMS v 12, Server hosted. I noticed the error Thursday night when I tried to save changes to some field modifications in a file, on the server it lets me make changes but won't let me commit them (via the OK button in the modify database window). In Pro, it won't let me make changes at all before giving me that error message. Haven't tried copying it to any other machines. There are a few machines running pro that are connected to the server network that this file runs from, I only typically use the server and one other client running pro connected to the network. No plug-ins installed that I know of.
EDIT: Also, I manually closed filemaker on each client after I got the message the first time, thinking it could've been an issue with someone that had left theirs open at the end of the day while editing or something but still recieved the message.
Restarting the server is the most obvious next step.
You do make backups.
You may also want to take a recent backup copy of this file and Run a Recover on it to check it for damage.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Thank you for your reply, if I need to do this, I'd like to do this in the most sensitive way possible to ensure that everything goes smoothly. Your information is great! Is there a tutorial that I can watch about this process as well that might be helpful? What would cause the corruption all of a sudden like that though?
Recover is pretty straight forward. I'm not sure what a tutorial could show you.
You may never know what causes damage to a file. One possible source of damage is making design changes to the file while it is hosted on the server. The chance of this is slight, but if you get a network "hiccup" right when changes are being committed back to the hosted file--particularly changes made in Manage | Database....
Okay, I'll take your word for it :). It is possible that the senario you've mentioned could be the problem in this case. Is this process a messy one or will it go fairly smooth without much issue so that I can make sure that I get everything back and going with all records and such to exactly the way they should be? Only wondering because I've never done this before and I want to make sure that I do it right without issue :).
If recover reports that a problem was found or if recover fixes the issue without reporting that a problem was found, your best bet is to run tests on your back up files to find the newest file that does not need the recover to work. You can open this file and use save a copy as with the clone option to get an empty copy of your database. Then you can go to your recovered copy of the file and do the following:
For each table in the file....
Go to a layout based on that table and select Show All Records.
Leave the file open.
Open the clone copy.
For each table in the clone file....
Go to a layout based on that table and select Import Records | File to import the data. Use the matching field names option to make sure that data is correctly imported.
Then update the next serial number value settings on any auto-entered serial numbers to make sure that they are least one larger than any serial number values in your imported data.
If you know how to create scripts, this process can be scripted--which keeps you from having to keep coming back to the computer and setting up the next import for the next table and makes sure that you don't forget to update a serial number field.