| Subject | Re: Integ_114 Constrait Violation |
|---|---|
| Author | Adam |
| Post date | 2006-08-02T10:17:42Z |
--- In firebird-support@yahoogroups.com, "Gaurav Sood"
<sood.gaurav@...> wrote:
a description of lots of different trees but missing the forest.
Unless you have managed to mix up some message files, the problem
appears to be that you have a unique constraint which is being
violated by an insert.
Attack it logically.
1. What is INTEG_114?
Looks like one of those wonderful automatically generated constraint
names. You do realise you can name each constraint which makes knowing
which field Firebird is unhappy with simple. In any case, you should
be able to find what field this constraint is on through the RDB$
tables (system tables). I do not have FB installed on this machine so
I can't give an exact query, but just use any database browsing tool
and you will find it.
2. Any triggers?
Before pulling your program to pieces, check whether the table has any
triggers that are being fired. A poorly written trigger may be setting
a particular value causing your problem.
3. Remove Delphi from the equation, generate a .sql file with the
exact DML you believe Delphi to be sending through, and confirm that
this is not your problem.
4. Are there other transactions going on at the same time? Could it be
that you have a record in another transaction not visible to your
transaction?
5. If it turns out to be a primary key, has someone been reducing the
value of a generator, or using the wrong generator? This can cause
this sort of problem.
6. In your Delphi code you appear to be addressing your field by
position (param maybe rather than field?). Are you sure it is field 4
you should be setting? Maybe try fieldbyname as a quick check.
Adam
<sood.gaurav@...> wrote:
>table
> Hi All,
>
> I am using a query to insert a number of fields into a database. The
> has several fields (some Smallint, string, and integer values). I alsowhen the
> previously tried using a D_BOOLEAN domain defined as Char(1). Even
> domain was defined to CHECK (VALUE IN ('T', 'F')), with the fielddeclared
> as 'NOT NULL DEFAULT 'F', I get this Unique or Primary key ConstraintThere is a lot of information in the post, but it seems largely a like
> INTEG_114 violation on my table.
a description of lots of different trees but missing the forest.
Unless you have managed to mix up some message files, the problem
appears to be that you have a unique constraint which is being
violated by an insert.
Attack it logically.
1. What is INTEG_114?
Looks like one of those wonderful automatically generated constraint
names. You do realise you can name each constraint which makes knowing
which field Firebird is unhappy with simple. In any case, you should
be able to find what field this constraint is on through the RDB$
tables (system tables). I do not have FB installed on this machine so
I can't give an exact query, but just use any database browsing tool
and you will find it.
2. Any triggers?
Before pulling your program to pieces, check whether the table has any
triggers that are being fired. A poorly written trigger may be setting
a particular value causing your problem.
3. Remove Delphi from the equation, generate a .sql file with the
exact DML you believe Delphi to be sending through, and confirm that
this is not your problem.
4. Are there other transactions going on at the same time? Could it be
that you have a record in another transaction not visible to your
transaction?
5. If it turns out to be a primary key, has someone been reducing the
value of a generator, or using the wrong generator? This can cause
this sort of problem.
6. In your Delphi code you appear to be addressing your field by
position (param maybe rather than field?). Are you sure it is field 4
you should be setting? Maybe try fieldbyname as a quick check.
Adam