RE: Válasz: Re: Insure DB consistency in case ofrecovery

["Shields, Ken" <kenshields@xxxxxxx>]

There may be, and I've seen it before, where the application set, because they 
realized in the design of the db, that the
journaling/restoration process would not serve their purpose, designed their 
own functional set of programs to journal for
their own purposes.
Trying to eliminate one or the other set of integrity data will jeopardize the 
data base.
It would appear, from my understanding of your situation, that BOTH sets are 
required.
Why not (if the project allows the time), verify the package data integrity 
methods, and if they check out, you may find
journaling may not be necessary on the DB2 side.
Perhaps some form of both , in sequence, may prove the best solution.
Ken

-----Original Message-----
From: Refaie.Heba@khb.hu [mailto:Refaie.Heba@khb.hu]
Sent: Friday, April 12, 2002 10:25 AM
To: midrange-l@midrange.com
Subject: Válasz: Re: Insure DB consistency in case ofrecovery


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.