Prev: FOR XML data vs Recordset
Next: Trouble with SQL2005 sp_cycle_errorlog
From: Whit Gregg on 3 Jul 2008 12:02
I'm running SqlServer-2005 SP2 x64
I am getting the following 2 Failed Assertions:

SQL Server Assertion: File: "xact.cpp" line = 2879 Failed Assertion =
'!m_updNestedXactCnt' Trying to use the transaction while there are 1
parallel nested xacts outstanding.


SQL Server Assertion: File: <lckmgr.cpp><c/> line=9421 Failed Assertion =
'NULL == m_lockList.Head ()'.


is there a fix or work-around for this?

Thanks.
--
Whit Gregg
Lek Securities Corp
New York, NY
From: Eric Isaacs on 3 Jul 2008 14:50
Sounds like you may be starting a new transaction when one is already
outstanding on the same process. If that's the case, then using this
syntax before starting your transactions, might help...

IF @@TRANCOUNT = 0
BEGIN TRANSACTION

-Eric Isaacs
From: Whit Gregg on 3 Jul 2008 15:06
Eric,
Thanks for the reply.
I don't think any code changes at the T-SQL level will help.
these ASSERTs are inside the guts of the SQL Database-Engine.
I looks like an internal SQL-Server bug to me.
now these ASSERTs themselves may only be reporting an
internal data inconsistency, and the real problem began somewhere else
in the internals. But I was hoping that Microsoft had seen this problem
before,
and could help resolve it, behaps with a QFE

--
Whit Gregg
Lek Securities Corp
New York, NY


"Eric Isaacs" wrote:

> Sounds like you may be starting a new transaction when one is already
> outstanding on the same process. If that's the case, then using this
> syntax before starting your transactions, might help...
>
> IF @@TRANCOUNT = 0
> BEGIN TRANSACTION
>
> -Eric Isaacs
>
From: TheSQLGuru on 3 Jul 2008 17:22
If you open up a support request with MS and the issue is found to be a bug
I don't think they charge you for the support call. If it is a bug and it
isn't known, others could benefit from your pursuing this one with them.

--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net


"Whit Gregg" <whit(a)newsgroups.nospam> wrote in message
news:687CD370-0C31-40EC-9832-916E983C986D(a)microsoft.com...
> Eric,
> Thanks for the reply.
> I don't think any code changes at the T-SQL level will help.
> these ASSERTs are inside the guts of the SQL Database-Engine.
> I looks like an internal SQL-Server bug to me.
> now these ASSERTs themselves may only be reporting an
> internal data inconsistency, and the real problem began somewhere else
> in the internals. But I was hoping that Microsoft had seen this problem
> before,
> and could help resolve it, behaps with a QFE
>
> --
> Whit Gregg
> Lek Securities Corp
> New York, NY
>
>
> "Eric Isaacs" wrote:
>
>> Sounds like you may be starting a new transaction when one is already
>> outstanding on the same process. If that's the case, then using this
>> syntax before starting your transactions, might help...
>>
>> IF @@TRANCOUNT = 0
>> BEGIN TRANSACTION
>>
>> -Eric Isaacs
>>


From: Linchi Shea on 3 Jul 2008 17:27
If it's critical, I'd open a support case. It's a SQL bug, and you wouldn't
be charged for teh case.

Linchi

"Whit Gregg" wrote:

> Eric,
> Thanks for the reply.
> I don't think any code changes at the T-SQL level will help.
> these ASSERTs are inside the guts of the SQL Database-Engine.
> I looks like an internal SQL-Server bug to me.
> now these ASSERTs themselves may only be reporting an
> internal data inconsistency, and the real problem began somewhere else
> in the internals. But I was hoping that Microsoft had seen this problem
> before,
> and could help resolve it, behaps with a QFE
>
> --
> Whit Gregg
> Lek Securities Corp
> New York, NY
>
>
> "Eric Isaacs" wrote:
>
> > Sounds like you may be starting a new transaction when one is already
> > outstanding on the same process. If that's the case, then using this
> > syntax before starting your transactions, might help...
> >
> > IF @@TRANCOUNT = 0
> > BEGIN TRANSACTION
> >
> > -Eric Isaacs
> >
 |  Next  |  Last
Pages: 1 2
Prev: FOR XML data vs Recordset
Next: Trouble with SQL2005 sp_cycle_errorlog