Hi Reggie,

i'm quite sorry, but i cannot reproduce your error.

For my testing i used a simple table without any active triggers. Its
primary key consists of one integer column.

I did the following steps:
1. gfix -v -f -no_update <<db>> to ensure, that the DB is OK.
2. Starting of 2 scripts on different clients with a lot of insert
statements into the table - one script produces a duplicate key error
on the primary key column. The duplicate key is one of the new values
inserted but not commited at this point of time by the other script.
The primary key consists of one integer column.
3. COMMIT of both scripts
4. gfix -v -f -no_update <<db>> and: No errors were reported.

Is my scenario the same as yours?

Regards
Micha

--- In ib-support@y..., "Reggie White" <reggiewhite@l...> wrote:
> We found an reproducible issue with Firebird about 2 months ago that
corrupt
> indexes.
> We reported privately to the head person at IBPhoenix, they were
able to
> reproduce the problem, but they have since stop responding to my
inquiries
> about the issue...so I doubt that it will be fix.
>
> Here is the scenario that we found:
>
> Create a table with a Primary Key on it.
> Have 2 different clients connected to the database.
> create 2 scripts (1 for each client) that will insert data into the
table.
>
> (This is where the problem comes in)
> In 1 of the scripts modify it so that it will create a duplicate
record.
>
> Have both clients run 1 of the scripts.
>
> After you have ran the script and received your duplicate error,
commit both
> clients.
>
> Now, from the server, run gfix -v -f -no_update. It should report
corrupt
> Index pages.
>
>
> The corruption does not occur if the duplicate line is removed, and
it does
> not occur if it's only 1 user is writing to the table at a time.
>
> Thanks