This randomly happened, the file is hosted and I am not sure what happened, besides recovery mode what else can I do?
This can happen when the server is restarted improperly perhaps through crash or server restart, particularly when either backups are happening or users are editing records (or schema being edited).
Recovery is your best option. If it was hosted on server I would hope you were running backups in which case another option is to restore from backup
If the recovery does detect issues with the file, a good option is to get an earlier copy of the system (e.g. from backup), clone it, and run the data migration tool from your corrupt (recovered) copy into the clone. this ensures the schema is clean, as often an issue in the data is not a big deal. You can also use the option on DMT to re-index fields to address any indexing issues that might have arisen, although this does take some time if you have a large system.
3 Likes
Sometimes, simply restarting the FileMaker client can help. The message often incorrectly indicates that the server-hosted database is damaged.
Jan
2 Likes
Thank you both for your replies, what we have done is
- Gone to a back up from the previous hour.
- File > Recover the database.
My question is I was running a replace field contents, but why would that break a file? It was 20k records while people were using the database.
@Drew what version of FMS and FMP are you using, and what OS are you running both on?
Bit of a non-sequitur: RFC skips updating records if that record is open, without any indication that it was skipped.
In most cases (RFC has its' place), a LOOP with a Set Field command, is the preferred approach, as you can trap for locked records and run again against those records.
1 Like
No, No, No, No. Don't do that. There will be tears.
Replace Field Contents doesn't care what happens to your data. If it can make the replacement: cool. If it can't make the replacement: who cares. You will never know what happened until you go looking.
As @Kirk has mentioned, looping through the records with an error check is a robust method for doing bulk replace.
You can also do an import. This is also subject to record lock conflicts but at least you get a status report and a log file to let you know if there were any errors.
My preference: an external file that has a 1 to 1 key relationship to the data you are going to modify. From the data source, export the IDs of the records you want to modify, and any fields that you need, saving as a FileMaker database. Open the file and add a relationship to the table in the data source based on the ID so that each record has a unique 1:1 relationship. Create data fields as needed to generate the data you are going to push across the relationship into the data source. Add a calc field which is localtable::field = datasource::field, to verify that the update is performed correctly. Now you can use Replace Field Contents, or a loop, or an import, and you can use the verification field to ensure that all data was transferred without error.
1 Like
Or use a loop within a transaction. Its either all succeed or all fail.
1 Like
Is it still April 1st?
1 Like
No it's the 5th today
- FileMaker Pro Version: 21.1.1.41 (released 09-28-2024)
- Operating System: macOS 14.7.4 (arm64)
Thank you Kirk and Malcom, this gives me something to talk to my coworkers about. I did not know RFC worked like this. I like your approach Malcom...
My experience has been that corruption warnings on a hosted file that are shown in FMP are almost always cache related issues, most often in FMP locally. Users with an unstable WAN network connection seem to be most prone to this.
Less frequently, the problem is on the server. The actual file on the server is fine though.
For FMP, use the Delete button in Settings to clear cache there.
For FMS, restarts FMS fully (usually a reboot is easiest)
The above does not rule out the possibility of corruption though. Just not the most likely issue in my opinion though.
1 Like