First, if there is the possibility of corrupted data, I would immediately export the data from Item A into a non-FileMaker file format, such as Excel or a tab- or comma-delimited file. Take a look at the data there and see what you have.
Second - how to compare - this depends on how your database is designed. Hopefully, you have included unique, key fields in each table. If that is the case - you could do a couple of things.
Import/Update records from the Item A export into Item B using the key field as the match. This will update all records in item B that have been modified in A with the most current data, as well as add any new records. Deleted records will not be updated, so they won't be in the found set after the import.
Check the key field or any serialized fields to see what the most recent serial number is, and compare that to the serial in item B - note this will ONLY tell you how many new records were added - NOT if any records were modified.
If you don't have a key field - then, unsorted records in both tables will be in creation order. So you could also export data from both into Excel or use a list view in FileMaker to compare each row. This is not very accurate, because the "missing" rows may not line up if any records were deleted after the backup. And again - will only show you if there are missing records, not necessarily if they were altered, but if it's the best you can do, it is something.
As soon as you restore the final data - add a key field to every table in your database.. This is best practice and is irreplaceable in cases like this.
Also recommend you migrate that file to a current version of FM ASAP.
Hope that helps.
Thanks for the tips. I'm trying to export the data into Excel .CSV and it keeps giving me messages like:
Summarizing field "A2 Data"...
Summarizing field "Total Staff"...
The table has 50,000 rows. I let it run for almost an hour and it seemed like it was in an infinite loop?
Any ideas on what's wrong and how to proceed?
Yes - Do not include summary fields or unstored calcs in your export. Since the data is unstored anyway, it does not need to be exported and the calculation slows you way down..
FM has to recalculate the unstored totals for each record when exporting - that is what is causing your delay.
Also - create a blank layout (no fields ) to do your export from - because if you are exporting from a layout that has the unstored calcs, summary fields on the layout, they will delay the export as well. That should speed things up. Shouldn't take long to do an export of this size.
Last - you did not say, but if you are exporting from a remote server (vpn or other WAN access ) this will still be too slow for this many records. Do the export from the LAN.