Tag Info

New answers tagged

0

The output is only showing the current query in a transaction. What else is in the BEGIN...COMMIT? Or are you running autocommit=0? Or =1? SELECT grabs shared locks on the rows it is looking at, for the duration of the transaction. INSERT grabs exclusive lock(s). It sounds like the SELECT already has a lock that the INSERT desires. Perhaps the SELECT ...


1

All three options you are looking at are bound to perform poorly in a concurrent environment. Wrapping SELECT (MAX(wid)) ... in a transaction won't prevent race conditions; you'd need to write-lock the entire table for that. If you don't need the sequence numbers to start from 1 for every branch, as long as the values are increasing and unique, you might ...


3

I was assuming that these new records will not be visible to the current transaction, but proved wrong on testing. That's not the case in the default READ COMMITTED isolation. Changes from committed transactions become visible at the start of the next statement in a transaction. Each statement still has a snapshot, so you can't have rows appear within a ...


1

I'd recommend keeping a few things in mind. You will want to be consistent no matter what you decide. For example, will you shorten 'transaction' to 'tx' so all of your stored procedures and scripts are easier to use? How often will you be changing it? Here are some good best cases from stackoverflow: Singular names for tables Singular names for ...


1

From BOL If a package that is not configured to support transactions includes a Sequence container that uses the Required option, the Sequence container would start its own transaction. If the package were configured to use the Required option, the Sequence container would join the package transaction. If I have a sequence container and it is marked ...


0

Yes you can. However, it depends on the internals of the System.Data.SqlClient assembly and so I would not recommend it. If it is truly required I would reassess if CLR is actually the correct way to do what you are trying to do. The SqlTransaction is actually only a wrapper class around the SqlInternalTransaction class. The SqlInternalTransaction class ...


1

XACT_STATE() is not something that SqlClient has any special insight on, much like transaction level. So, just query it with SqlCommand. // If you already have an open connection... public int GetXactState (SqlConnection connection) { using (SqlCommand command = new SqlCommand("Select XACT_STATE();", connection)) { return ...


0

I spent a while in a test environment trying to reproduce your issue and have had some success. If I set up Log Shipping in its most basic form, and in such a way as to mimic your situation, everything appears to be working. However, I have found one way to configure the environment that results in messages similar to yours... Message 1: Message 2: ...



Top 50 recent answers are included