>...
>
> The worst hassle are the customer IDs. I had to allow for new customer records to be created independently on each site (they have trouble communicating with the central), just taking care they remain unique, and then had to create a routine for the central site to put those codes together, because same customers may appear at several sites. Now when a temp ID is replaced with a permanent ID, I have to scan for all the records with that customer's ID and replace it for the new one, plus mark these records for distribution, plus keep this temp ID in a separate field in the customer table, because by the moment the ID is updated in the central, there may be new records with this temp ID at outer sites, so they'd have to be updated later when they arrive....
>
>...
>
>This is the problem I envisage - unique ID's are no problem (I use a HUB-ID and append it to each primary key) but the possibility of a record appearing twice and not being automatically 'welded' is worrying: I could only think of 'flagging' the record(s) at one or other site and prompting for human intervention.

The record doesn't appear twice, but a customer does, and gets two distinct records (because he appears at two sites and gets two temporary codes), accompanied with detail records. These should be put together, and there's no other way but to tell the user in the central that "there are temporary IDs, wanna fix'em"; "now;later". The trouble is that these customers (actually, cooperating farmers; I said customers just to bring the story into a known context) receive loans in money and/or stuff, and one may appear at two places and take double, before getting detected. Another trouble is that they can't be compared easily, since the sites are in a villages, where many names repeat (specially in villages with Hungarian minority, where father and son often have the same first name), so full identification takes the address as well. I didn't even think about any means of automatic recognition; I just aid the user with a temporary index based on For(sound(name))=..., but still have to give a chance for full table search - can't rely on names to be properly spelled, nor on addresses.

>Thanks for all the answers: I'll just have to keep searching...or write my own [hair turns grey, hands shake]

I've earned my first grays in Cobol :)