Re: Best way to reconcile data

>
> What types of changes are you referring to in this regard? You really
> haven't provided much in thewayof usable information with this
> post. Much more detail (or a decent example) would be helpful.
>
> David Fitzjarrell

I will try to do my best with an example, David.

Assume we have a table with orders, and obviously have another child table with order lines. Users do routinely - daily - add and update orders. Such data awe call live data.

Assume further that we have a third table with products (eg wine, bread, ...). That table is rarely changed, perhaps a few times in a month. Such data we call setup data.

An order line represents an ordered quantity of a product. It therefore has a foreign key to the product table.

People would like to :

1. take out of the production database P a copy of the setup data - the product table.
2. get it into another setup database/schema S.
3. Change the products in S, while users still add or update or delete orders in P.
4. Integrate back the changed products in P, and have it all automagically working.

I *think* it is doable if the only statements allowed on products in S are updates
and inserts, and if the product table in P is frozen in the mean time.

However, I have to say that I am sliiiiightly frightened by the risk analysis and mitigations that are needed to make it foolproof :-)))

Surely that problem has been solved
somewhere already. Or not ?

• Raoul