Re: Removing constraints

Right. But primary key constraints, in a typical iSeries environment are
actually specified in the DDS.

If you are using SQL DDL and specify the primary keys as constraints,
separate from the definition of the table, then, again, you can apply
them from the DDL source. That's just a learned thing.

I'm not implying that there isn't some other underlying problem with the
save and restore, but, with full SQL DDL sources, you should be able to
readily repair any constraint damage caused by the save restore, and
only have to rely on the table data making it back.

Managed DDL sources have everything ordered by drop, create table,
create primary keys, create unique keys, create inversion keys, create
foreign keys, create value constraints. They can then be applied by
range, even in the CA SQL execution utilities.

Question, did you ever resolve if the save was done with ACCPTH(*YES)?


On Sat, 2005-04-02 at 18:52, David Gibbs wrote:
> David Gibbs wrote:
> > In fact, the current schema
> > that we're finding isn't even logical.  There are foreign key
> > constraints on files that should have a primary key constraint, but the
> > primary key constraint isn't there.
> 
> That didn't sound right.
> 
> Let me try to restate it ... there are files with foreign key
> constraints that point to other files with primary key constraints, but
> the primary key constraints are missing.
> 
> When I restored the library, a bunch of diagnostic messages were logged
> indicating that the constraints were invalid... and they complained
> about files that should have had primary key constraints, but they were
> missing.
> 
> david
-- 
"Bigamy is having one wife too many. Monogamy is the same."
-- Oscar Wilde