New answers tagged

0

make backup of data for some case then go to mysql bin folder and run mysqld --tc-heuristic-recover=ROLLBACK don't forget to restart mysql after source: http://lampretard.blogspot.com/2016/01/you-have-to-start-mysqld-with-tc.html


3

Have you tried profiling a single session to see if/when its transaction is promoted to distributed? For example, using a server side trace using e.g. the DTCTransaction (and maybe TM: Promote Tran xxx) event classes. You can also monitor detailed DTC activity in Windows. I would profile all the likely looking connection, execution, and transaction-related ...


1

This is probably best to insert all items at once or at least avoid have to split string on the SQL Server side. You could convert json to xml similar to this: <Order OrderId="" OrderDate="" CustomerId="" Price="300"> <Items> <Item ItemId="103" Qty="2" Price="100" /> <Item ItemId="123" Qty="2" Price="100" /> ...


2

In addition to the types of errors noted by @Aaron (i.e. Severity >= 19 and conversion failures), the following types of errors, noted in the MSDN page for TRY...CATCH, will also abort a batch: The following types of errors are not handled by a CATCH block when they occur at the same level of execution as the TRY…CATCH construct: Compile errors, ...


2

if any errors, roll the whole thing back; It's simpler than you seem to think. Any exception in a transaction (that is not trapped somehow) triggers a ROLLBACK for the whole transaction automatically. You don't have to do anything extra. BEGIN; CREATE TABLE IF NOT EXISTS blah ( ... ); -- much more DDL COMMIT; You cannot start, commit or roll back ...


5

I believe there are a few exceptions, but from Database Engine Error Severities (MSDN): Error messages with a severity level of 19 or higher stop the execution of the current batch. Errors that terminate the database connection, usually with severity from 20 through 25, are not handled by the CATCH block because execution is aborted when the ...


0

There are a couple of issues here. Firstly, some errors terminate the current statement and some (an inconsistent and rare few) terminate the whole batch. set XACT_ABORT on makes statement terminating errors become batch aborting errors (which is good because it forces some consistency). The problem here is that each of these go statements mark the ...


0

Check with the business team to see if you can restructure the business process so that you can start and comit a new transaction for each row in the excel file. If anything failed, record the fail rows so that they would know which row was successful and which one failed



Top 50 recent answers are included