Re: Removing constraints

[R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx>]

in a word... ErWin.

It sounds like either you don't have a source member that created this
schema or you have lost control of the source that was used to create
the schema, or... most likely on the iSeries, you didn't have one to
begin with. Someone just kept adding things on with command line
options.

ErWin or similar products (I also have used Embarcadero's products with
great success on the iSeries) allow you to manage that type of thing.
Then the source can be save to the IFS as well as on PC's.

In a recovery situation, the sql source for generating the schema and
all constraints can be applied and checked for errors.

On the 400 there's WRKPFCST for dealing with pending issues (data that
does not allow the constraint to be enforced). But of course, the
constraint must first exist.

As far as collecting the information to begin with, well, if the
constraints _have_ been applied to the tables in the schema, then most
reverse engineering products, like ErWin and ERStudio, can extract the
information. Even some parts of CA and WDSC can extract some of this
information, but I have not relied on either of those for serious DB
work.





On Sat, 2005-04-02 at 13:22, David Gibbs wrote:
> David Gibbs wrote:
> >>>I'm not sure how the constraints were removed though ... and find
> >>>it odd that a primary key constraint could be removed when a
> >>>foreign key constraint depends on it.  Kind of like deleting a
> >>>physical file when a logical file is built over it.
> >>perhaps SAVLIB save accesspaths(*NO)?
> > Some of the constraints are there ... but not all of them.
> 
> On a similar note ... does anyone know of a way to test a database to
> make sure that all the necessary constraints are valid?
> 
> When I restored the database on our system (and when the customer
> restored it from a backup on their system) there were a number of errors
> (previously mentioned) that indicates that some of the constraints were
> invalid because the dependent (mostly primary key constraints) were missing.
> 
> It's my suspicion that the ORIGINAL database was fine, but the restored
> database had it's constraints screwed up when it was restored.
> 
> I've asked our customer to open a PMR with IBM to pursue this issue ...
> but in our efforts to repair the database, we would like to try and make
> sure the database hasn't lost anything else.
> 
> Thanks!
> 
> david
-- 
"Bigamy is having one wife too many. Monogamy is the same."
-- Oscar Wilde