Subject | Re: Duplicate keys |
---|---|
Author | Adam |
Post date | 2005-10-12T23:36:13Z |
--- In firebird-support@yahoogroups.com, "Stephen Boyd"
<sboydlns@y...> wrote:
to time if you give that logic enough load. The exists check will
return false if there is a duplicate that is not visible to you (yet).
If you are literally getting duplicate records (ie the insert is
succeeding, then the problem may be elsewhere, certainly worth
investigating. It is nothing that I have experienced though.
Adam
<sboydlns@y...> wrote:
>In that case, I would expect to see a primary key violation from time
> --- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
> >
> > Stephen,
> >
> > I think this might have been a bit of a wild goose chase. The
> problem
> > may not be a bug or corruption after all, but rather transaction
> > isolation.
> >
> >
> > Even if TrA committed before TrB does anything, unless TrB is read
> > committed, it will not see the record.
> >
> > If you need to define a field as unique, then add it as a constraint
> > on the table. Otherwise, your system is not safe for simultaneous
> > transactions. Even if your transactions are read committed, I have
> > included a case where it is possible to create duplicates.
> >
> > Adam
> >
> It is a constraint on the table. LDSI_STOP_ID and LDSI_ITEM_NUMBER
> comprise the primary key.
>
to time if you give that logic enough load. The exists check will
return false if there is a duplicate that is not visible to you (yet).
If you are literally getting duplicate records (ie the insert is
succeeding, then the problem may be elsewhere, certainly worth
investigating. It is nothing that I have experienced though.
Adam