...
| PROD_ID | AMOUNT_RECEIVED |
|---|---|
| 101 | 250 |
When the following SQL is issued on the source database:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
update SALES set AMOUNT_RECEIVED = 120 where PROD_ID = 101;
The replicated SQL that is applied on the target database is as follows (note the WHERE clause contains the old value of AMOUNT_RECEIVED):
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
update SALESset AMOUNT_RECEIVED = 120
where (1=1)
and AMOUNT_RECEIVED =250
250 and PROD_ID = 101;
If in the meantime, another transaction on the target database had changed AMOUT_RECEIVED from 250 to another value (say 199), then the above update would affect zero rows and the conflict would occur. This is because the WHERE clause (AMOUNT_RECEIVED = 250) would not be satisfied.
This ensures that the user is notified and no previous data will be lost.