Re: Válasz: Re: Insure DB consistency in case of recovery

Maybe some kind of trigger on the application files? Add it just before
recovery, remove afterwards? Then every record added to app database would
result in activity in your internal files. Maybe.

At 04:25 PM 4/12/02 +0200, you wrote:
>This is a multipart message in MIME format.
>--
>[ Picked text/plain from multipart/alternative ]
>Actually I was looking for a way to maintain the referential integrity
>between our files and application files.
>
>For example, if we have an order and order detail file in the application
>database, and for some reason we have an internal developed file containg
>extra order details. The recovery of the application failed to enter the
>order data in the original application database for any reason, but the
>APYJRNCHG to our external file was successful. Someone has to check the DB
>consistency after recovery using a query for example and my manager does
>not like this although I think such a case is very exceptional. but it be
>be some idea to overcome this...
>
>thanks in advance
>Heba
>
>
>
>
>
>Vernon Hamberg <vhamberg@attbi.com>
>Feladó: midrange-l-admin@midrange.com
>2002.04.12 16:10
>Kérem, válaszoljon ennek a személynek: midrange-l
>
>
>                     Címzett: midrange-l@midrange.com
>                     Másolat:
>                        Tárgy: Re: Insure DB consistency in case of recovery
>
>
>You must mean the check constraint. This is not a part of DDS. The RANGE,
>COMP, and VALUES keywords do not stop you from putting invalid values into
>a record with SQL. These attributes can be copied to a display file field
>as a REFFLD, where the various check mechanisms can generate error
>messages.
>
>At 09:28 AM 4/12/02 -0400, you wrote:
> >This is an area where I am not proficient in HOW to do this, I am
>somewhat
> >knowlegeable only in WHAT can be done.
> >
> >One of the nice things about DB/2 is that you can put rules in the
>definition
> >of files, that trump 100% of your programs.
> >
> >For example, you could say that some specified field can never be a
>negative
> >number.
> >It does not matter who or how anything tries to make it so ... user tool,
> >application software bug, it aint going to be violated.
>
>-snip-
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
>list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.