Jack:

At 08:14 PM 6/06/2003 -0400, you wrote:

>There are two tables, contributors and contributions. It should be
>Contributions. I sent the wrong DDL. Here it is:
>
>RECREATE TABLE CONTRIBUTIONS
>(
> CONTRIBUTIONNR INTEGER NOT NULL,
> DONORNR INTEGER,
> EVENTNR INTEGER,
> DONATIONDATE DATE,
> DONATIONTYPE CHAR( 20) CHARACTER SET
>NONE COLLATE NONE,
> DONATIONVALUE DECIMAL( 9, 2),
> DEDICATION CHAR( 20) CHARACTER SET
>NONE COLLATE NONE,
> DONATIONVEHICLE CHAR( 20) CHARACTER SET
>NONE COLLATE NONE,
> NOTES VARCHAR( 10000) CHARACTER SET
>NONE COLLATE NONE
>);

Now, the next thing we need to look at are the following:

1) the actual DDL for any other foreign key constraints relating to EITHER
of the tables involved in THIS FK relationship

2) the ACTUAL text of the FK violation message, which you described
originally like this:

The error is: exception class EIBO_ISCError with message 'ISC ERROR
CODEE:335544466. ISC ERROR MESSAGE: violation of FOREIGN KEY constraint
"name" on table "name" statement: TIBOInternalDataset: "<TApplication>.form
name.query name".

Because I suspect that the FK violation is occurring because of another
relationship than the one at hand.

I'm also dubious about seeing the use of RECREATE TABLE in a conversion
process. This command will destroy any constraints existing on the
original table. IOW, you appear to be using an awkward and error-prone
approach to this conversion.

We can't tell from your problem description so far whether you are trying
to combine DDL and DML inside a single transaction. This is not
recommended except by the very experienced - notwithstanding that the very
experienced would also know the benefits of separating metadata creation
from data creation into separate, protected transactions, and would know to
avoid it unless all the i's were dotted and the t's crossed first. (Catch-22).

The problem description itself is pretty confusing so far. For example,
you said:
"My FB database has a number of one-on-many relationships with
auto-numbering triggers for all primary keys and foreign-key constraints to
parent tables, where needed."

Thus, it's easy to see where you might have Before Insert triggers that are
breaking the relationships that you assume you are importing from Access.

I'm afraid I simply don't have time to play guessing games like "20
Questions". A complete review of the problem description and your
assumptions about it may actually lead you to find the cause without
further outside help (best case) or at least provide those willing to help
with more to go on.

Helen