>Hi Erik,
>Each file has a name of SiteID + XportID, so the names of the .ZIP files are unique. Each file is imported, but the order is critical. Each system knows the last importID from each site, so a warning is issued if an ID is skipped. If the record is changed/corrected on the Importing site, I use a DELETE and INSERT INTO, so a new record with the Importer's siteid is created. That new record is sent back when the importer sends the next export. This way, all sites should have the same data.
>
>Here is the scenario that I'm thinking of.
>A site creates some records in various tables. Each record has a SiteID, XportID, and it's own KeyID. All records that haven't been exported are selected and we replace all the XportID's with the XportLog's KeyID. Those records are sent to the next site. The import process would find each record and determine if it is already there, and if so, the same data. If the record is already there, and different, but not yet exported from this site, it is overwritten. If it has been exported already, the changes are written to a log, but otherwise lost. There are some special routines for detail items where the header record has been given a stamp of approval (exported), so the changes are not accepted and are lost--well written to a log, but lost.
>I don't have a skipping stone situation as Shane described. Once the records are exported from the next site, no changes to a specific record are allowed by the original site.
>
>Charlie
>>I have tackled the same problem in a similar fashion- but I am curious- how does your scheme handle 2 packages from the same site in rapid succession? Will the first file be overwritten and the changes lost?

Gotcha.