Helen,

the SP is called many times from the client and the SP performs a single
insert only. The TimeStamp value is generated from the client app because it
has to be Universal Coordinated time (or whatever it is called) because we
have clients in different timezones. What I observe is occasional periods
(which typically last for a couple of hours) where each record is double
entered and then a few weeks when everything works just fine.

By the way what do people think about the suggestion of a NowUTC function so
that the server can generate timestamps in universal time - i use timestamps
a lot for logging and replication purposes, and with clients in the UK and
USA it has to be UTC?

Kind regards,
Pete Bray

> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: 02 August 2001 00:01
>
> At 08:15 PM 01-08-01 +0100, you wrote:
> >Hmmm!
> >would this occur in the case of a simple SP which performs an
> insert. I have
> >an SP which inserts into a log table where i have not defined a
> PK (the SP
> >does not have a suspend), every now and then i see duplicate
> entries which
> >are logged with the same time stamp?
>
> 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.
>
> 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...
>
> 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.
>
> Helen
>