> -----Original Message-----
> From: Ann Harrison [mailto:harrison@...]
> Sent: Jueves 1 de Junio de 2000 10:07
> Jim said, I hope, that we don't know of a performance problem with
> large numbers of duplicates for insert or select. We all know about
> the problem with garbage collection after an index value in a long
> duplicate chain is deleted or changed.

Clarified and noted. Thanks.

> What's the solution? Don't define the FK but perform the
> >lookup in the BEFORE INSERT trigger with a select/exists construction?
>
> No, referential integrity is more reliable than triggers because it
> is not bound to transaction context.

Seems you were well awakened when reading that. You understood the point
that wasn't said explicitly. Actually, I've put a little article on my site
because I received several private inquiries... newbies didn't figure out
that transaction isolation affected triggers to check for referential
integrity.

> > I won't continue piggybacking the kinobi.performance NG here
> > unless ISC
> >people want to continue here in parallel.
>
> No, I'll go back to the performance list.
> Thanks,
> Ann

Thanks you, too. Three weeks later, a posting from a not IB-used person
suggested that IB was 120 times slower than Sybase. After some digging
thanks to Holger Klemt, the issue resulted to be... guess what? The ODBC
driver!

C.