EXECUTE के बाद ट्रांजेक्शन काउंट BEGIN और COMMIT स्टेटमेंट की बेमेल संख्या को दर्शाता है। पिछली संख्या = 1, वर्तमान गणना = 0

Question 1

मेरे पास एक Insertसंग्रहीत प्रक्रिया है जो डेटा को फीड करेगी Table1और Column1मूल्य प्राप्त करेगी और Table1दूसरी संग्रहीत प्रक्रिया को कॉल करेगी जो टेबल 2 को खिलाएगी।

लेकिन जब मैं दूसरी संग्रहीत प्रक्रिया कहता हूं:

Exec USPStoredProcName

मुझे निम्नलिखित त्रुटि मिलती है:

EXECUTE के बाद ट्रांजेक्शन काउंट BEGIN और COMMIT स्टेटमेंट की बेमेल संख्या को दर्शाता है। पिछली संख्या = 1, वर्तमान गणना = 0।

मैंने इस तरह के अन्य सवालों के जवाब पढ़े हैं और यह पता लगाने में असमर्थ हूं कि वास्तव में प्रतिबद्ध गणना कहां गड़बड़ हो रही है।

Question 2

यदि आपके पास TRY / CATCH ब्लॉक है, तो संभावित कारण यह है कि आप एक ट्रांज़ैक्शन एबॉर्ट अपवाद को पकड़ रहे हैं और जारी रखें। CATCH ब्लॉक में आपको हमेशा XACT_STATE()उपयुक्त गर्भपात और अक्षम (डूमेड) लेनदेन की जांच करनी चाहिए । यदि आपका कॉलर लेन-देन शुरू करता है और कैली हिट करता है, तो कहें, एक गतिरोध (जिसने लेन-देन निरस्त कर दिया है), कॉलली को संचार करने के लिए कैली कैसे जा रहा है कि लेन-देन निरस्त कर दिया गया था और इसे 'व्यापार की तरह सामान्य रूप से' जारी नहीं रखना चाहिए? एकमात्र संभव तरीका एक अपवाद को फिर से उठाना है, जिससे कॉलर को स्थिति को संभालने के लिए मजबूर किया जा सके। यदि आप चुपचाप एक निरस्त लेन-देन को निगल लेते हैं और फोन करने वाला यह मानता है कि मूल लेनदेन में अभी भी है, केवल तबाही सुनिश्चित कर सकता है (और आपको जो त्रुटि मिलती है वह उसी तरह है जैसे इंजन खुद को बचाने की कोशिश करता है)।

मेरा सुझाव है कि आप अपवाद हैंडलिंग और नेस्टेड लेनदेन पर जाएं जो एक पैटर्न दिखाता है जिसका उपयोग नेस्टेड लेनदेन और अपवादों के साथ किया जा सकता है:

create procedure [usp_my_procedure_name]
as
begin
    set nocount on;
    declare @trancount int;
    set @trancount = @@trancount;
    begin try
        if @trancount = 0
            begin transaction
        else
            save transaction usp_my_procedure_name;

        -- Do the actual work here

lbexit:
        if @trancount = 0
            commit;
    end try
    begin catch
        declare @error int, @message varchar(4000), @xstate int;
        select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
        if @xstate = -1
            rollback;
        if @xstate = 1 and @trancount = 0
            rollback
        if @xstate = 1 and @trancount > 0
            rollback transaction usp_my_procedure_name;

        raiserror ('usp_my_procedure_name: %d: %s', 16, 1, @error, @message) ;
    end catch
end
go

Question 3

मुझे यह समस्या भी हुई। मेरे लिए, कारण यह था कि मैं कर रहा था

return
commit

के बजाय

commit
return

एक संग्रहीत प्रक्रिया में।

Question 4

यह आम तौर पर तब होता है जब लेनदेन शुरू किया जाता है और या तो यह प्रतिबद्ध नहीं होता है या यह रोलबैक नहीं होता है।

यदि आपके संग्रहीत कार्यविधि में त्रुटि आती है, तो यह डेटाबेस तालिकाओं को लॉक कर सकता है क्योंकि अपवाद हैंडलिंग की अनुपस्थिति में कुछ रनटाइम त्रुटियों के कारण लेनदेन पूरा नहीं हुआ है। आप नीचे दिए गए अपवाद हैंडलिंग का उपयोग कर सकते हैं। XACT_ABORT को सेट करें

SET XACT_ABORT ON
SET NoCount ON
Begin Try 
     BEGIN TRANSACTION 
        //Insert ,update queries    
     COMMIT
End Try 
Begin Catch 
     ROLLBACK
End Catch

स्रोत

Question 5

इस बात से अवगत रहें कि यदि आप नेस्टेड लेन-देन का उपयोग करते हैं, तो एक रोलबैक ऑपरेशन बाहरी-सबसे एक सहित सभी नेस्टेड लेनदेन को वापस रोल करता है।

यह TRY / CATCH के संयोजन में उपयोग के साथ, आपके द्वारा बताई गई त्रुटि के परिणामस्वरूप हो सकता है। अधिक देखें यहाँ ।

Question 6

यह तब भी हो सकता है यदि आपकी संग्रहीत प्रक्रिया लेनदेन खोलने के बाद संकलित विफलता का सामना करती है (जैसे तालिका नहीं मिली, अमान्य स्तंभ नाम)।

मैंने पाया कि मुझे 2 संग्रहीत प्रक्रियाओं को एक "कार्यकर्ता" एक और एक रैपर का उपयोग करना था, जिसमें रेमस रुसानु द्वारा उल्लिखित तर्क के समान दोनों को पकड़ने / पकड़ने की कोशिश की गई थी। वर्कर कैच का उपयोग "सामान्य" विफलताओं को संभालने के लिए किया जाता है और कम्पाइलर विफलता त्रुटियों को संभालने के लिए रैपर को पकड़ा जाता है।

https://msdn.microsoft.com/en-us/library/ms175976.aspx

त्रुटियां एक TRY से प्रभावित ... CATCH निर्माण

निम्नलिखित प्रकार की त्रुटियों को एक CATCH ब्लॉक द्वारा नियंत्रित नहीं किया जाता है जब वे TRY के रूप में निष्पादन के समान स्तर पर होते हैं ... CATCH परिणाम इस प्रकार हैं:
संकलित त्रुटियां, जैसे वाक्यविन्यास त्रुटियां , जो बैच को चलने से रोकती हैं।

कथन-स्तर पुनर्संयोजन के दौरान होने वाली त्रुटियां, जैसे ऑब्जेक्ट नाम रिज़ॉल्यूशन त्रुटियां, जो आस्थगित नाम रिज़ॉल्यूशन के कारण संकलन के बाद होती हैं।

उम्मीद है कि यह किसी और को डीबगिंग के कुछ घंटे बचाने में मदद करता है ...

Question 7

मेरे मामले में, त्रुटि RETURNअंदर से हुई थी BEGIN TRANSACTION। तो मेरे पास कुछ ऐसा था:

Begin Transaction
 If (@something = 'foo')
 Begin
     --- do some stuff
     Return
 End
commit

और यह होना चाहिए:

Begin Transaction
 If (@something = 'foo')
 Begin
     --- do some stuff
     Rollback Transaction ----- THIS WAS MISSING
     Return
 End
commit

Question 8

मेरे लिए व्यापक डिबगिंग के बाद फिक्स एक साधारण लापता थ्रो था; रोलबैक के बाद पकड़ में बयान। इसके बिना यह बदसूरत त्रुटि संदेश है जिसे आप समाप्त करते हैं।

begin catch
    if @@trancount > 0 rollback transaction;
    throw; --allows capture of useful info when an exception happens within the transaction
end catch

Question 9

मेरे पास एक ही त्रुटि संदेश था, मेरी गलती यह थी कि मुझे COMMIT TRANSACTION लाइन के अंत में एक अर्धविराम मिला था

Question 10

मुझे अपने लेन-देन से इस कथन को छोड़ने के बाद एक बार इस त्रुटि का सामना करना पड़ा।

COMMIT TRANSACTION [MyTransactionName]

Question 11

मेरी राय में स्वीकृत जवाब ज्यादातर मामलों में एक ओवरकिल है।

त्रुटि का कारण अक्सर बेगिन और COMMIT का बेमेल है जैसा कि त्रुटि द्वारा स्पष्ट रूप से कहा गया है। इसका उपयोग करने का अर्थ है:

Begin
  Begin
    -- your query here
  End
commit

के बजाय

Begin Transaction
  Begin
    -- your query here
  End
commit

इस त्रुटि का कारण बनता है!

Question 12

सुनिश्चित करें कि आपके पास एक ही प्रक्रिया / क्वेरी में एक से अधिक लेनदेन नहीं हैं, जिसमें से एक या एक से अधिक को छोड़ दिया गया है।

मेरे मामले में, मैंने गलती से क्वेरी में BEGIN TRAN बयान दिया था

Question 13

यह उस तरीके पर भी निर्भर कर सकता है जिस तरह से आप अपने सी # कोड से एसपी को आमंत्रित कर रहे हैं। यदि SP कुछ तालिका प्रकार मान लौटाता है, तो SP को ExecuteStoreQuery के साथ आमंत्रित करें, और यदि SP कोई मान नहीं लौटाता है तो ExecuteStoreCommand के साथ SP को आमंत्रित करें

Question 14

प्रयोग करने से बचें

RETURN

बयान जब आप उपयोग कर रहे हैं

BEGIN TRY
    ... 
END TRY

BEGIN CATCH
    ...
END CATCH

तथा

BEGIN, COMMIT & ROLLBACK

एसक्यूएल संग्रहीत प्रक्रियाओं में बयान

Question 15

यदि आप किसी चीज़ की कोड संरचना कर रहे हैं जैसे:

SELECT 151
RETURN -151

फिर उपयोग करें:

SELECT 151
ROLLBACK
RETURN -151