SqlTransaction problem???

[perspolis]

Hi all
I have a master-detail tables in sql server.
I use SqlTransaction to insert data into both tables.
it works well but if I check the "Cascade Delete Related Records" option in
it's realtion in sql server my SqlTransaction dosen't work and get timeout
error..

please help me
thanks in advance

 

[Sahil Malik [MVP C#]]

There are so many factors that could be causing this

- What kind of locks are you generally getting on your table - are they
page locks? Is the pk index clustered?
- What exactly is your update logic like? DataAdapter.Update will only
affect one single table, so how exactly are you getting master-detail to
work?
- Does this happen in concurrent scenarios or single user scenarios?
- Is it unpredictable in general?
- other reasons ..

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[Marc Gravell]

You don't mention if you are using DataAdaptors etc, so I'm going to
assuming you are (like me) rigging your own Sql using the ADO.NET command,
connection and transaction objects directly...

If you are getting a timeout error doing a delete (of any kind, but
especially cascading), there are two big causes:

1: your delete is going on a killing spree and is just taking a long time
because deleting 1 header record means deleting 2134245 detail records
2: (more likely) you are getting consistently blocked

So - if you are getting this behaviour consistently it seems likely that you
are, in fact, blocking yourself. Do you have any other open connections (and
more importantly, transactions) operating on this data from the same client?
Are you perhaps doing multiple (nested) transactional sql calls on different
transactions?

e.g. (in pseudo code)

Delete(data) {
Create Conn
Begin Tran
Call SP1 for data on the above conn/tran
AdditionalMethod(data)
Commit Tran
Close Conn
}

AdditionalMethod(data) {
Create Conn
Begin Tran
Call SP2 for data on the above conn/tran
Commit Tran
Close Conn
}

The above layout will inevitably block when attempting SP2 because SP1 has
the locks, and isn't going to release them until the Commit Tran in
Delete(); Since you are using Sql-Server, when you execute your code, and
before the timeout fires (try upping it for debugging), you should be able
to use sp_who in the database to see who is blocking you (look for a
non-zero entry in the blk column, and then find the row with that value in
the spid column); probably the login and host on the offending row are
yours. If the blocking spid is 82 (for instance) you can then call dbcc
inputbuffer(82) to see what the last command executed on that connection
was.

If your situation is anything like the above, the solution (obviously) is to
ensure that both the calls execute on the same transaction, for instance by
passing the transaction as a parameter to the AdditionalMethod

Of course it could also be that somebody else with access to the database
has just left their transaction open for 5 hours ;-p (easily done if you are
debugging something in T-SQL and then go to a long meeting...)

Marc

 

[perspolis]

Hi
I used it in single session and I call SqlDataAdaptor for tow tables first
Master then Details and my pk is clustered..
and I use the BeginTransatcion of SqlConnection with default
mode(Serialaizable)..

 

[Sahil Malik [MVP C#]]

Okay that clarifies a bit.

First of all, the default mode(I think you meant isolation level) is
ReadCommitted for both SQL Server and Oracle - not Serializable.

Secondly, this approach won't work. When you start working with hierarchical
data, you need to add rows from the parent table first, followed by adding
the relevant child rows. Updates need to follow adds, because you could both
add a new master row, and modify a detail row to use the FK of the newly
added row. But updates need to follow the same path Master->Detail. Deletes
however need to follow the reverse path, or you will simply get FK errors,
because details need to be removed before the master can be.

Not only that, in this scenario, you would have the delete page locks
causing locks with inserts and updates page locks, and if you lock too much,
the db may end up locking tables - so essentially you cannot predict what
transactions cause locks in what.

So what do you do?

Well obviously, you need a different persistence mechanism, my book's
chapter 10 explains dealing with hierarchical data in detail. But in short,
you need to respect the relationships in your persistence mechanism - in
addition to rowstates. A few things you could try are using non clustered
indexes, and controlling the connection opening yourself rather than having
the dataadapter do it for you. That *may* help , but not necessarily in
all situations. Search my blog for "Pessimistic locking is your friend" for
a detailed explanation on the ideal solution for hierarchical data. That
pretty much describes the ferrari approach - the mostest perfectestest
solution. But you may just be okay with a Honda. Anyway, there is more to
this than I can type right now in a newsgroup reply, but I gave you some
pointers to poke around on

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx