Subject | Re: problem solved...in part |
---|---|
Author | Rick Roen |
Post date | 2007-11-08T23:39:43Z |
Thanks Helen,
I don't think that was it since DBWorkbench notifies you if you close
a table that has pending changes which I always did before pumping
the data.
Also I did it numerous times from scratch since I kept getting
corrupt.
Another thing was that I tried to import the data first and then
create the FK. In this case when I tried to commit the FK, the
message came up about the consitancy check, so I was unable to save.
I know the data did not violate the FK since I check via a query and
also the same data later worked after I restored the DB and then
pumped.
I have more to do on this new DB, so I'll see if it happens again in
a way I can reproduce it.
Rick
in the data.
created yet.
I don't think that was it since DBWorkbench notifies you if you close
a table that has pending changes which I always did before pumping
the data.
Also I did it numerous times from scratch since I kept getting
corrupt.
Another thing was that I tried to import the data first and then
create the FK. In this case when I tried to commit the FK, the
message came up about the consitancy check, so I was unable to save.
I know the data did not violate the FK since I check via a query and
also the same data later worked after I restored the DB and then
pumped.
I have more to do on this new DB, so I'll see if it happens again in
a way I can reproduce it.
Rick
> I think possibly the original problem arose because you didn'tcommit the transaction that performed the DDL before starting to pump
in the data.
>because it had not been committed, the enforcing index was not
> internal gds software consistency check (partner index description
> not found (175))
>
> At that point the engine knew a foreign key had been requested but,
created yet.
>before commencing any DML operations.
> Always keep DDL and DML in separate transactions and commit all DDL
>
> ./heLen
>