Prev: Multimedia and internet keys of the keyboard not working under VO apps
Next: Problem date comparision 2010
From: Geoff Schaller on 23 Jan 2010 21:07
Bernhard.

Are you saying that simply executing that statement gives you a
deadlock?

That would be very strange indeed so I suspect there is more to the
story. For example, give us a full function we can execute for
ourselves:

Function Start()

.... create the connection
.... create the statement
.... create the AdoServer
.... close the server

RETURN

If you isolate all code to just these few statements, does it run or
still provide the deadlock? I suspect you aren't closing something in
your main app on the connection and thus causing your own deadlock
through the implicit transaction you create behind the scenes.

Write the select against some system table in Master so that we can try
it.

Geoff




"Bernhard Mayer" <Idonotexisthere(a)nowhere.com> wrote in message
news:4b4c415d$0$1550$91cee783(a)newsreader04.highway.telekom.at:

> Dear fellow VO'ers!
>
> At our largest customer we are getting deadlock errors which we could not
> solve up to now.
>
> Error: Transaction (Process ID 70) was deadlocked on lock resources with
> another process and has been chosen as the deadlock victim. Rerun the
> transaction.
> Subsystem: Vo2Ado
> Error Subcode: 16389
>
> Mostly the call stack of the error is located in AdoServer:Init; I don't
> really understand why the message says something about transactions - every
> call stack we got up to now is nowhere near something as a transaction, we
> use AdoServer only for reading purposes.
>
> Sample:
>
> cStmt := "Select FieldA, FieldB,..... from ORDERS where ..."
> oServer := AdoServer{cStmt, oConn, adOpenForwardOnly, adLockReadOnly,
> adCmdText}
>
> The information we got from google did not really help us so far; we tried
> to use BEGIN SEQUENCE + Error blocks to catch the error but so far we did
> not succeed. Another problem is that the deadlock error seems to terminate
> the database connection and the whole app crashes.
>
> Could anyone help me with this problems?
>
> using SQL Server 2005 32 bit Standard Edition, SP 2
> VO 2.832, VO2Ado 2.8 prof., the AdoConnection cursor type is adUseClient
>
> TIA,
> Bernhard

From: Bernhard Mayer on 25 Jan 2010 01:50
Geoff,

"Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> schrieb im Newsbeitrag
news:0YN6n.3062$pv.2681(a)news-server.bigpond.net.au...
> Bernhard.
>
> Are you saying that simply executing that statement gives you a deadlock?

Yes, Meinhard explained it quite well; I didn't know that MS SQL Server
handles even plain select statements in transactions but unfortunately I
could not find the equivalent for VO2Ado to the SQL classes settings he
mentioned.

If you produce enough update statements against one table and concurrently
query select statements on the same table you'll get the error saying that
some of the processes - usually the select statement as it has a lower
priority - was chosen as the deadlock victim.

In the meantime we could wrap an error block around the AdoServer Init
method and capture the error but of course it would be much more nice to
make MS SQL Server not to automatically handle select statements in
transactions.

As for the other point: All our Ado server objects are closed if they are
not needed any more - I often do checks in this matter as in the past
unclosed Ado server objects were one oft the most severe causes for not
releasing memory.

BR,
Bernhard

From: Geoff Schaller on 25 Jan 2010 02:30
Bernhard,

I want you to prove to me this is the case. My suspicion is that you are
in fact doing something wrong so I would like to see the code that
causes this. Hence my challenge to reproduce it in a Function Start().
There are a lot of folks in this NG now on SQL Server using VO2Ado and
none of us experience this problem. If it were class based or MS SQL
Server based, you would expect others to have the same problem. They
don't.

Try a few variations such as client side cursors (which would be
normal). Avoid forward read only server side cursors unless you really
know that is what you want. Normally you would buffer on the client, not
the server. For VO it is more efficient. Check all the cursor defaults
and make sure you close all recordsets once done with them.

Geoff



"Bernhard Mayer" <Idonotexisthere(a)nowhere.com> wrote in message
news:4b5d3f41$0$1543$91cee783(a)newsreader04.highway.telekom.at:

> Geoff,
>
> "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> schrieb im Newsbeitrag
> news:0YN6n.3062$pv.2681(a)news-server.bigpond.net.au...
>
> > Bernhard.
> >
> > Are you saying that simply executing that statement gives you a deadlock?
>
>
> Yes, Meinhard explained it quite well; I didn't know that MS SQL Server
> handles even plain select statements in transactions but unfortunately I
> could not find the equivalent for VO2Ado to the SQL classes settings he
> mentioned.
>
> If you produce enough update statements against one table and concurrently
> query select statements on the same table you'll get the error saying that
> some of the processes - usually the select statement as it has a lower
> priority - was chosen as the deadlock victim.
>
> In the meantime we could wrap an error block around the AdoServer Init
> method and capture the error but of course it would be much more nice to
> make MS SQL Server not to automatically handle select statements in
> transactions.
>
> As for the other point: All our Ado server objects are closed if they are
> not needed any more - I often do checks in this matter as in the past
> unclosed Ado server objects were one oft the most severe causes for not
> releasing memory.
>
> BR,
> Bernhard

First  |  Prev  | 
Pages: 1 2
Prev: Multimedia and internet keys of the keyboard not working under VO apps
Next: Problem date comparision 2010