Oliver Jowett wrote:
>
> Merely having a prepared statement or resultset referencing the table
> does not hold locks. The only thing that holds locks (AFAIK) is an open
> transaction that did something requiring a lock. So perhaps you have an
> open transaction on another connection that used the table but has not
> yet called commit()/rollback(), or you have a concurrently executing
> query that holds the lock?
>
> -O
>
Well, thats good (but utterly confusing to me) to know... I'm not
running any transactions, and nothing else is going on concurrently that
I'm aware of. But it gives me a new direction to go hunting in. I've
certainly spent enough time checking for unclosed resultsets and
prepared statements. I know that the lock is being held by my code, I
just don't know where. Funny thing is, this code is written to work on
multiple databases - and I don't have any issues at all on DB2, MySQL,
Oracle, MSAccess, or Hypersonic DB. Just Postgres, in this one set of
queries. Which is starting to make me think I've uncovered a driver
bug... I'm going to spend more time today trying to figure out which
exact query of mine is establishing the lock.
Dan
--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/