--- In ib-support@y..., Helen Borrie <helebor@d...> wrote:

> The SQLDA bug doesn't occur on the server side, i.e. if your SP does

multiple inserts during one call, all will work. It occurs when the
same SP is called repeatedly without being reprepared and unprepared
between calls. It is caused by a certain field in the SQLDA structure
not being reset properly between client calls.

>

In my practice (IBX) this bug usually appears as AV in gds32. I've
never encountered it with BDE within 5 years, so I think it was
properly served in BDE. There are attempts to overcome it in FIBC by
G.H. Deatz and IBX by repeat call. In FIBC and early IBX including 4.2
this attempt had bug itself - application was not informed about lock
conflicts. I corrected it in my own "version" by properly serving of
isc_deadlock (335544336). In 4.42 Jeff made the same but with
isc_lock_conflict (335544345). Being not shure what is more right, I
added own code to Jeff's. Don't know about modern IBX, I stopped on
4.42. Why I told all this. If I understand right and report of double
execution came from IBO group, maybe it is bug in one of IBO versions
in similar attempt? I have about 500 hardly exploited SPs in my
database and I'm absolutely shure no one of them never was executed
twice (I support some kind of stored aggregates with SPs and regularly
check accordance with general data that can't be duplicated).

> It's possible your duplicate timestamps might come about NOT from

this bug but because (I believe) CURRENT_TIMESTAMP is actually the
timestamp for the COMMIT, meaning multiple inserts inside the same
transaction will always get the same timestamp. Now I might have this
confused and this observation applies to the 'NOW" literal, with
CURRENT_TIMESTAMP being the creation timestamp...

>

One more possible reason - loggeg events occures fast enough to be
saved within the same time quantum. I stepped on this rake some years
ago when tryed to make Date (TimeStamp) a PK for one of my log tables.
Helen, you can easy cooperate with FB developers, I beg you to make
more exact your knowledge about what is "NOW" when stamping records on
before triggers and as default value, and tell it here. If it is
really time of commit (I never had this idea), it is a key for many
problems of replication-like tasks.

> And the bug IS logged - I logged it myself a long time ago - [

#233025 ] Server hangs when executing Stored Proc more than once.
Somebody assigned it to priority 9 and I pushed it back up to 5.

>

I suppose it is high enough priority, if this bug will be fixed on
proper level, client's connectivity components will be free from
shamanism around it on improper one.

Best regards.