(FirebirdCS-1.0.0.796-0 running as user 'firebird', redhat 7.2 on i386
(AMD Duron), kinterbasdb 3.0.2, python 2.2.2, perl 5.8.0, DBD::InterBase
0.40.)

first i create an empty database using isql, and then chgrp it so the
'firebird' user can write to it. then i run the following python code
(which basically [re]create a simple table and fill it with 20,000 rows):

>>>

import kinterbasdb
import sys
def p(s): print s; sys.stdout.flush()

p("Connecting...")
con = kinterbasdb.connect(
dsn="localhost:/home/david/1.gdb",
user="sysdba",
password="pass"
)
cur = con.cursor()

p("Recreating table...")
try: cur.execute("DROP TABLE T1")
except kinterbasdb.ProgrammingError: cur=con.cursor()
cur.execute("CREATE TABLE T1 (i INT NOT NULL PRIMARY KEY, s VARCHAR(250))")
con.commit()

p("Inserting...")
for i in range(20000):
cur.execute("INSERT INTO T1 VALUES (?,?)", (1,''))

p("Committing...")
con.commit()
<<<

and execution fails at the second row insert because of the integrity
constraint: 'violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on
table "T1"'. the program exits. when i check with isql, T1 is empty as
expected as the first insert was rolled back.

then i run the program again. this time, all rows are inserted
successfully! after the program completes, i check with isql. there is
20,000 records, each with i=1. 'USE INDICES' shows:

RDB$PRIMARY2 UNIQUE INDEX ON T1(I)

so the PK index is still there. (right?)

i wrote an equivalent perl script using DBD::InterBase, and it produces
the same thing.

is this normal? what should i do to enforce PK? i'm baffled.

--
dave