Helen Borrie wrote:

>Perhaps you could help us by explaining why you need foreign keys on such
>columns.
>
>
>
>>I really dont understand why that is a trouble in firebird.Must be
>>another solution. I dont want to remove foreign keys and lost
>>referential integrity.
>>
>>
>
>Maybe you and we have different notions of "referential integrity". For
>example, one would not create a table to implement declarative referential
>integrity on a two or three state condition that won't change: one would
>create a domain with a CHECK constraint.
>
>create domain d_paytype char(6)
>CHECK (VALUE IS NULL OR VALUE IN('CASH', 'CHEQUE','CREDIT'));
>
>
>
>

Helen, maybe why have different concepts. AFAIK any data reusable must
be in a table. Sound more logic to have that kind of items in tables and
not *hardcoded* inside a check. What happens if i need to use a new kind
of payment in both cases?

In your option, i need to go to the database and modify the domain and
the constraint. My option, just insert a record.
What happens if i need to use another database technology not supporting
that kind of constraint? What happens if i need to use different names
to the same type of payment, by example?

Anyway, why that work fine in Access and not in Firebird? Something is
wrong there.
So you confirm that is the trouble? A few values inside the foreign
keys? So the solution can be deleting that keys?
Thanks for you help.

German.