Hi Dragan,

Your scenario sounds familiar. And I am afraid with me it will be with a vengeance as they say on CNN. I intend to do the same with inventory records that have to fit in the inventories of all the sites but can be parcels can created (i.e. allocated a number via mix and sort transactions) in any site, even in sites where the goods are not physically present.

Wish me luck.

Regards.

Marc



>>>I've done it once for a wheat merchant, who had four silos with computers on the site - each site was given a characteristic prefix, which prefixed all the PKs of the records they created in all of the tables, and that was used for synchronizing with the central. They also gave temporary IDs (with the same prefix) to their customers (i.e. peasants), and then these temporary IDs were (supposed to be) replaced with regular IDs in the central. There was some two-way updating routine which replaced the IDs in both incoming and outgoing data, which was somewhat tricky to do, but it generally worked. We had much more trouble with bad phone lines and bad floppies than with the logic itself.
>>
>>Sounds simple enough. But between the idea and its realisation, sometimes it's good to have Dragan confirm that it's been done.
>>
>>Thanks. It sure does help.
>
>OK, let me warn you of the troubles: the temporary IDs tend to become permanent (which doesn't matter, actually, they're unique), because the checking for a customer having two IDs needs human involvement, and it doesn't happen. Look at this scenario:
>
>A customer first appears at site A, and gets a temporary ID A0015. He makes an order, then he visits another site and gets a new temporary ID there as B0098, and makes another order. The central gets these data later, and if they don't pay attention that one customer has two IDs now, they can have a technicolor sh*t if the customer does something quick and wrong, like exceeding credit limits or whatever. Furthermore, the later they synchronize the IDs, the bigger the chances of a customer getting wise and taking advantage. You can look for similar names between the regular customers and customers with temp IDs, but all you can do is issue a warning - and you won't believe how easily they neglect it.
>
>We knew this in advance, and wanted to force them to check for the new codes on the phone with the central first, but that couldn't possibly work, because of the ugly combination of awful phone lines and rush hour.
>
>BTW, if you're interested in seeing the code, it's rather generic in the import/export part, and the logic of the synchronization of the temp IDs is not that complicated - email me.