hasta_l3_at_hotmail.com wrote:
>> 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
>
>
Check Oracle Lite also. Might be the solution.
It's used on offline kind of applications with reconcile functionality.
cheers,
pedro
Received on Sun Jun 10 2007 - 19:38:39 CDT
