At 09:29 AM 04-06-02 +0200, you wrote:

>Hi again, John.
>
>jbeh2000 wrote:
> > As I understand it the update all occurs within the context of a
> > single transaction and I therefore don't understand what the lock
> > conflict is.
>
>Well, I'm no good with stored procedures, but to me your code looks
>pretty OK and ought to work. The fact that nobody else (not even Helen)
>has replied to your question, indicates that there is no obvious error.

Actually, to be honest, I looked at it and thought "Oh dear, so much
correlation.." and hoped someone else would step in and help unravel
it. I'm guessing that, *if* the lock conflict has anything to do with the
SP, it might be an exasperated attempt by the engine to let you know that
you can't do a searched update using criteria that won't actually be
discerned as "existing" until the work of the SP is committed.

I think it is really stretching credibility a bit far to think that you can
request an update on the output of a SP that both executes DML and outputs
a dataset. I was trying to work out why you had to do it that way at
all...it would have been much simpler to do the update as part of the
execution of the SP. Let executable procedures be executable-only and
selectable procedures be selectable-only.

That's why I didn't reply - oh, and because I have flu and my brain hurts.

heLen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________