Can a recompile lock up system tables?

One developer complained he could not use EM to see the list of UDFs,
it seemed hung. Running sp_who2 showed another developer was blocking
him. This second developer had been running a hundred lines of code
in QA, and had aborted the batch. Apparently this left the
transaction hanging open, we see that a lot. But my question is, how
did this end up blocking EM from enumerating UDFs? What else was
locked out? Is this serious, or just a problem with EM?
I speculate that SQLServer decided to recompile a UDF inside of this
transaction, and that aborting it somehow left the lock in place on
some important system table. Is this likely?
Thanks.
J.jxstern wrote:
> One developer complained he could not use EM to see the list of UDFs,
> it seemed hung. Running sp_who2 showed another developer was blocking
> him. This second developer had been running a hundred lines of code
> in QA, and had aborted the batch. Apparently this left the
> transaction hanging open, we see that a lot. But my question is, how
> did this end up blocking EM from enumerating UDFs? What else was
> locked out? Is this serious, or just a problem with EM?
> I speculate that SQLServer decided to recompile a UDF inside of this
> transaction, and that aborting it somehow left the lock in place on
> some important system table. Is this likely?
> Thanks.
> J.
If you stop a transaction from Query Analyzer, then you must issue a
rollback if you are in a transaction. If you don't, you leave the
transaction open. The procedure could have accessed a system table and
without the rollback, left the locks in place on the table.
David Gugick
Quest Software
www.imceda.com
www.quest.com

Can a recompile lock up system tables?

One developer complained he could not use EM to see the list of UDFs,
it seemed hung. Running sp_who2 showed another developer was blocking
him. This second developer had been running a hundred lines of code
in QA, and had aborted the batch. Apparently this left the
transaction hanging open, we see that a lot. But my question is, how
did this end up blocking EM from enumerating UDFs? What else was
locked out? Is this serious, or just a problem with EM?
I speculate that SQLServer decided to recompile a UDF inside of this
transaction, and that aborting it somehow left the lock in place on
some important system table. Is this likely?
Thanks.
J.jxstern wrote:
> One developer complained he could not use EM to see the list of UDFs,
> it seemed hung. Running sp_who2 showed another developer was blocking
> him. This second developer had been running a hundred lines of code
> in QA, and had aborted the batch. Apparently this left the
> transaction hanging open, we see that a lot. But my question is, how
> did this end up blocking EM from enumerating UDFs? What else was
> locked out? Is this serious, or just a problem with EM?
> I speculate that SQLServer decided to recompile a UDF inside of this
> transaction, and that aborting it somehow left the lock in place on
> some important system table. Is this likely?
> Thanks.
> J.
If you stop a transaction from Query Analyzer, then you must issue a
rollback if you are in a transaction. If you don't, you leave the
transaction open. The procedure could have accessed a system table and
without the rollback, left the locks in place on the table.
David Gugick
Quest Software
www.imceda.com
www.quest.com

Can a recompile lock up system tables?

One developer complained he could not use EM to see the list of UDFs,
it seemed hung. Running sp_who2 showed another developer was blocking
him. This second developer had been running a hundred lines of code
in QA, and had aborted the batch. Apparently this left the
transaction hanging open, we see that a lot. But my question is, how
did this end up blocking EM from enumerating UDFs? What else was
locked out? Is this serious, or just a problem with EM?
I speculate that SQLServer decided to recompile a UDF inside of this
transaction, and that aborting it somehow left the lock in place on
some important system table. Is this likely?
Thanks.
J.
jxstern wrote:
> One developer complained he could not use EM to see the list of UDFs,
> it seemed hung. Running sp_who2 showed another developer was blocking
> him. This second developer had been running a hundred lines of code
> in QA, and had aborted the batch. Apparently this left the
> transaction hanging open, we see that a lot. But my question is, how
> did this end up blocking EM from enumerating UDFs? What else was
> locked out? Is this serious, or just a problem with EM?
> I speculate that SQLServer decided to recompile a UDF inside of this
> transaction, and that aborting it somehow left the lock in place on
> some important system table. Is this likely?
> Thanks.
> J.
If you stop a transaction from Query Analyzer, then you must issue a
rollback if you are in a transaction. If you don't, you leave the
transaction open. The procedure could have accessed a system table and
without the rollback, left the locks in place on the table.
David Gugick
Quest Software
www.imceda.com
www.quest.com

Can a recompile lock up system tables?

One developer complained he could not use EM to see the list of UDFs,
it seemed hung. Running sp_who2 showed another developer was blocking
him. This second developer had been running a hundred lines of code
in QA, and had aborted the batch. Apparently this left the
transaction hanging open, we see that a lot. But my question is, how
did this end up blocking EM from enumerating UDFs? What else was
locked out? Is this serious, or just a problem with EM?
I speculate that SQLServer decided to recompile a UDF inside of this
transaction, and that aborting it somehow left the lock in place on
some important system table. Is this likely?
Thanks.
J.jxstern wrote:
> One developer complained he could not use EM to see the list of UDFs,
> it seemed hung. Running sp_who2 showed another developer was blocking
> him. This second developer had been running a hundred lines of code
> in QA, and had aborted the batch. Apparently this left the
> transaction hanging open, we see that a lot. But my question is, how
> did this end up blocking EM from enumerating UDFs? What else was
> locked out? Is this serious, or just a problem with EM?
> I speculate that SQLServer decided to recompile a UDF inside of this
> transaction, and that aborting it somehow left the lock in place on
> some important system table. Is this likely?
> Thanks.
> J.
If you stop a transaction from Query Analyzer, then you must issue a
rollback if you are in a transaction. If you don't, you leave the
transaction open. The procedure could have accessed a system table and
without the rollback, left the locks in place on the table.
David Gugick
Quest Software
www.imceda.com
www.quest.com