Subject | Re: [ib-support] Handling multiple locations |
---|---|
Author | Raymond Kennington |
Post date | 2002-08-24T06:32:22Z |
Joe,
My reply doesn't solve your problem. Instead, it discusses deeper issues involved.
There are 2 parts to the problem.
First, you must address the asynchronicity of the data entry and specify a protocol that
works. There is probably a known protocol to solve this problem. If you don't find one,
then I'd strongly suggest using a protocol engineering tool or consult a protocol engineer
to ensure you have a solution that works.
As there is a time lag between checking for an existing customer in another database that
may be offline and posting of that customer, the name may be stored in 2 databases. This
could also occur if a customer is represented by more than one person, so that 2 people
could be making the same request from 2 different sales sights.
The 2nd part involves identifying the first site that has stored the customer's details.
Due to the asynchronous nature of the situation this cannot be guaranteed. If you -could-
identify the first database that a customer's details were entered into, then you could
add a field identifying the first site and make that field part of the PK.
You have also mentioned the issue: What if the user wants to change address or phone
details?
This is in the realm of -distributed database systems-.
Raymond Kennington
My reply doesn't solve your problem. Instead, it discusses deeper issues involved.
There are 2 parts to the problem.
First, you must address the asynchronicity of the data entry and specify a protocol that
works. There is probably a known protocol to solve this problem. If you don't find one,
then I'd strongly suggest using a protocol engineering tool or consult a protocol engineer
to ensure you have a solution that works.
As there is a time lag between checking for an existing customer in another database that
may be offline and posting of that customer, the name may be stored in 2 databases. This
could also occur if a customer is represented by more than one person, so that 2 people
could be making the same request from 2 different sales sights.
The 2nd part involves identifying the first site that has stored the customer's details.
Due to the asynchronous nature of the situation this cannot be guaranteed. If you -could-
identify the first database that a customer's details were entered into, then you could
add a field identifying the first site and make that field part of the PK.
You have also mentioned the issue: What if the user wants to change address or phone
details?
This is in the realm of -distributed database systems-.
Raymond Kennington
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/