XAL 3.50.1 and SQL Server 2005 Deadlocks...

Hello,

We have upgraded from SQL 2000 to SQL 2005. We have big problems with 
deadlocks. We never had deadlocks before, but we think the problem is in 
XALSEQ.
Can anaybody give some advise on how to avoid deadlocks ?
we are familiar with TTS and LockList..
We are using kernel 3.50.1 

PNI

Hi, Paul,

I am not sure, whether my comments will help solving your issue. However it 
is something you should keep in mind, when trying to fix the deadlock problem.

At first, I would like to hint to the fact, that Microsoft SQL Server 2005 
is not supoorted on XAL kernel 3.50.1, but is supported in XAL kernel 3.55.1 
and higher.
So I recommand upgrading the XAL kernel to a version, which supports 
Microsoft SQL Server 2005.

Another recommendation stems from the fact, that Microsoft SQL Server 2005 
comes with a newer MDAC version than the one supported by XAL 3.50.1. You can 
enforce compatibility between XAL and SQL Server 2005 by specifying the XAL 
start parameter -zzH26 . I am not sure, whether this compatibility may come 
with a performance loss.

If there is still a problem with the deadlocks, then you should check the 
application for possibilities to cut large transactions into smaller 
sub-transactions. If the update of the table XALSEQ is performed during a TTS 
on any table, the table XALSEQ will remain locked, until the transaction on 
the other table is closed. By using smaller sub-transactions, you unlock the 
table XALSEQ faster.

Kind regards 
Hannsjörg Zdarsky
Software Design Engineer
Microsoft Deutschland GmbH


"Paul" wrote:

> Hello,
> 
> We have upgraded from SQL 2000 to SQL 2005. We have big problems with 
> deadlocks. We never had deadlocks before, but we think the problem is in 
> XALSEQ.
> Can anaybody give some advise on how to avoid deadlocks ?
> we are familiar with TTS and LockList..
> We are using kernel 3.50.1 
> 
> PNI
> 

Hi Hannsjörg,

Thanks for your answer ! 
We are already using the -zzH26 startup parameter.

I have checked the kernel newsletters and fixlist very carefully, but i had 
the impression that 3.55 was more a gui update. (Although using the mouse 
scroll wheel in forms is more than a gui update).
We used the 3.55 kernel also, but the deadlocks where still there.

Can you give me a clue on doing queries from microsoft office on the SQL Xal 
Tables ?
Do you know the optimal configuration of SQL Server for XAL ?, In case of 
multi processor in the server, should we allow parralel queries or not ?

Thanks
Paul 

"Hannsjörg Zdarsky (Microsoft)" wrote:

> Hi, Paul,
> 
> I am not sure, whether my comments will help solving your issue. However it

> is something you should keep in mind, when trying to fix the deadlock
problem.
> 
> At first, I would like to hint to the fact, that Microsoft SQL Server 2005

> is not supoorted on XAL kernel 3.50.1, but is supported in XAL kernel
3.55.1 
> and higher.
> So I recommand upgrading the XAL kernel to a version, which supports 
> Microsoft SQL Server 2005.
> 
> Another recommendation stems from the fact, that Microsoft SQL Server 2005

> comes with a newer MDAC version than the one supported by XAL 3.50.1. You
can 
> enforce compatibility between XAL and SQL Server 2005 by specifying the XAL

> start parameter -zzH26 . I am not sure, whether this compatibility may come

> with a performance loss.
> 
> If there is still a problem with the deadlocks, then you should check the 
> application for possibilities to cut large transactions into smaller 
> sub-transactions. If the update of the table XALSEQ is performed during a
TTS 
> on any table, the table XALSEQ will remain locked, until the transaction on

> the other table is closed. By using smaller sub-transactions, you unlock
the 
> table XALSEQ faster.
> 
> Kind regards 
> Hannsjörg Zdarsky
> Software Design Engineer
> Microsoft Deutschland GmbH
> 
> 
> "Paul" wrote:
> 
> > Hello,
> > 
> > We have upgraded from SQL 2000 to SQL 2005. We have big problems with

> > deadlocks. We never had deadlocks before, but we think the problem is
in 
> > XALSEQ.
> > Can anaybody give some advise on how to avoid deadlocks ?
> > we are familiar with TTS and LockList..
> > We are using kernel 3.50.1 
> > 
> > PNI
> > 

Hello James,

thnx for your answer, but it's not possible to set compatibility mode to 90, 
XAL SQL generates severe errors and you are not able to retrieve any data.


Regards Paul

"James" wrote:

> Maybe try setting the database compatability as mode 80 which will put 
> SQL2005 in SQL200 mode I believe.  If things are then okay I guess its some

> new feature config in your SQL2005
> 
> 
> "Paul" <Paul@discussions.microsoft.com> wrote in message 
> news:E5C05AC1-93B6-41CB-BFE4-645BBBBBEF4E@microsoft.com...
> > Hi Hannsjörg,
> >
> > Thanks for your answer !
> > We are already using the -zzH26 startup parameter.
> >
> > I have checked the kernel newsletters and fixlist very carefully, but
i 
> > had
> > the impression that 3.55 was more a gui update. (Although using the
mouse
> > scroll wheel in forms is more than a gui update).
> > We used the 3.55 kernel also, but the deadlocks where still there.
> >
> > Can you give me a clue on doing queries from microsoft office on the
SQL 
> > Xal
> > Tables ?
> > Do you know the optimal configuration of SQL Server for XAL ?, In case
of
> > multi processor in the server, should we allow parralel queries or not
?
> >
> > Thanks
> > Paul
> >
> > "Hannsjörg Zdarsky (Microsoft)" wrote:
> >
> >> Hi, Paul,
> >>
> >> I am not sure, whether my comments will help solving your issue.
However 
> >> it
> >> is something you should keep in mind, when trying to fix the
deadlock 
> >> problem.
> >>
> >> At first, I would like to hint to the fact, that Microsoft SQL
Server 
> >> 2005
> >> is not supoorted on XAL kernel 3.50.1, but is supported in XAL
kernel 
> >> 3.55.1
> >> and higher.
> >> So I recommand upgrading the XAL kernel to a version, which
supports
> >> Microsoft SQL Server 2005.
> >>
> >> Another recommendation stems from the fact, that Microsoft SQL
Server 
> >> 2005
> >> comes with a newer MDAC version than the one supported by XAL
3.50.1. You 
> >> can
> >> enforce compatibility between XAL and SQL Server 2005 by
specifying the 
> >> XAL
> >> start parameter -zzH26 . I am not sure, whether this compatibility
may 
> >> come
> >> with a performance loss.
> >>
> >> If there is still a problem with the deadlocks, then you should
check the
> >> application for possibilities to cut large transactions into
smaller
> >> sub-transactions. If the update of the table XALSEQ is performed
during a 
> >> TTS
> >> on any table, the table XALSEQ will remain locked, until the
transaction 
> >> on
> >> the other table is closed. By using smaller sub-transactions, you
unlock 
> >> the
> >> table XALSEQ faster.
> >>
> >> Kind regards
> >> Hannsjörg Zdarsky
> >> Software Design Engineer
> >> Microsoft Deutschland GmbH
> >>
> >>
> >> "Paul" wrote:
> >>
> >> > Hello,
> >> >
> >> > We have upgraded from SQL 2000 to SQL 2005. We have big
problems with
> >> > deadlocks. We never had deadlocks before, but we think the
problem is 
> >> > in
> >> > XALSEQ.
> >> > Can anaybody give some advise on how to avoid deadlocks ?
> >> > we are familiar with TTS and LockList..
> >> > We are using kernel 3.50.1
> >> >
> >> > PNI
> >> >
> >> > 
> 
> 

Maybe try setting the database compatability as mode 80 which will put 
SQL2005 in SQL200 mode I believe.  If things are then okay I guess its some 
new feature config in your SQL2005


"Paul" <Paul@discussions.microsoft.com> wrote in message 
news:E5C05AC1-93B6-41CB-BFE4-645BBBBBEF4E@microsoft.com...
> Hi Hannsjörg,
>
> Thanks for your answer !
> We are already using the -zzH26 startup parameter.
>
> I have checked the kernel newsletters and fixlist very carefully, but i 
> had
> the impression that 3.55 was more a gui update. (Although using the mouse
> scroll wheel in forms is more than a gui update).
> We used the 3.55 kernel also, but the deadlocks where still there.
>
> Can you give me a clue on doing queries from microsoft office on the SQL 
> Xal
> Tables ?
> Do you know the optimal configuration of SQL Server for XAL ?, In case of
> multi processor in the server, should we allow parralel queries or not ?
>
> Thanks
> Paul
>
> "Hannsjörg Zdarsky (Microsoft)" wrote:
>
>> Hi, Paul,
>>
>> I am not sure, whether my comments will help solving your issue.
However 
>> it
>> is something you should keep in mind, when trying to fix the deadlock 
>> problem.
>>
>> At first, I would like to hint to the fact, that Microsoft SQL Server 
>> 2005
>> is not supoorted on XAL kernel 3.50.1, but is supported in XAL kernel 
>> 3.55.1
>> and higher.
>> So I recommand upgrading the XAL kernel to a version, which supports
>> Microsoft SQL Server 2005.
>>
>> Another recommendation stems from the fact, that Microsoft SQL Server 
>> 2005
>> comes with a newer MDAC version than the one supported by XAL 3.50.1.
You 
>> can
>> enforce compatibility between XAL and SQL Server 2005 by specifying the

>> XAL
>> start parameter -zzH26 . I am not sure, whether this compatibility may

>> come
>> with a performance loss.
>>
>> If there is still a problem with the deadlocks, then you should check
the
>> application for possibilities to cut large transactions into smaller
>> sub-transactions. If the update of the table XALSEQ is performed during
a 
>> TTS
>> on any table, the table XALSEQ will remain locked, until the
transaction 
>> on
>> the other table is closed. By using smaller sub-transactions, you
unlock 
>> the
>> table XALSEQ faster.
>>
>> Kind regards
>> Hannsjörg Zdarsky
>> Software Design Engineer
>> Microsoft Deutschland GmbH
>>
>>
>> "Paul" wrote:
>>
>> > Hello,
>> >
>> > We have upgraded from SQL 2000 to SQL 2005. We have big problems
with
>> > deadlocks. We never had deadlocks before, but we think the problem
is 
>> > in
>> > XALSEQ.
>> > Can anaybody give some advise on how to avoid deadlocks ?
>> > we are familiar with TTS and LockList..
>> > We are using kernel 3.50.1
>> >
>> > PNI
>> >
>> >