Make a back up copy of your current file.
Use a find to pull up all the records you want to restore in your back up in a found set and leave the file open.
Use Import records to import these records into your current file. (If the file is open, Import records imports from the current found set.)
You can either use the update matching records option if there's a field with a unique ID or you can first delete the records from your current copy before importing the records from your back up.
If you choose to delete the records, be careful to make sure no table of related records is set up to also be deleted when a matching record in this table is deleted or you'll delete more than you intend.
Assuming you have a unique ID field:
1. In your live database, do a Find for the 160 records.
2. Do an Import and select your backup.
(If the backup was closed, you're all set. If it was open, you should check that in the backup file all records are found, or optionally, find the records you want to import.)
3. Choose the "Update matching records in found set" and select the appropriate match field.
This will replace the selected fields in the current file with data from the backup.
These records do not have a common identifier in order to perform a find that will bring them all up. So, i don't know if that solution will work...eek.
Some how you were able to identify the records that needed restoring. You'll need to use that information to locate the records you want to restore if possible...
You can still do this, though it can take a bit of work.
Here are some possibilities:
You may be able to perform a find that finds all the records but also a few more records.
If so, find the them and then omit the records that don't need restoring.
You can also build a series of find requests each of which find some of the records.
You can enter find mode and enter criteria to find one group of records,
Choose new request and enter criteria ot find a second group.
Repeat as needed
Perfrom the find and you'll find the records matching the first criteria or the second and so forth.
You can review these records and omit extras if needed.
"These records do not have a common identifier in order to perform a find that will bring them all up. So, i don't know if that solution will work...eek"
I believe that now you realize that EVERY table should have a unique, FM-generated auto-enter serial number (which is meaningless). Some people think it would only be necessary if the table is used in relating records to other tables but it is also important if you have to synch or restore records.
As Tom says, "3. Choose the "Update matching records in found set" and select the appropriate match field." But you can use several fields in your match. For instance, if you have creation timestamp, user name and/or several other fields which DIDN'T change, you can use those fields as match fields.
So consider all your fields and see how many might be used. You can even create a concatenation of those fields (in both your current table and your backup table) and then search the concatenation for ! (which is duplicate) to see if you've used fields which produce unique (within the single table). Be sure to skip any fields which might have changed. And if you do that, just use that concatenation field as your single match on both sides (copy it from your target table into your source table so it matches perfectly).
A concatenation calculation ( result is text ) might look like:
UserName &"|" & CreationTimeStamp & "|" & HireDate & "|" & BirthDate & "|" & ZipCode & "|" & SS#
The idea is to make every record unique by only concatenating those fields which you KNOW didn't change from either current file or backup.
UPDATE: You can add a field to 'x' the ones for the change and then perform a find for records with an 'x' in this flag field to isolate your record set for the replacement.