XACT_ABORT চালু করা থাকলে কোন ক্ষেত্রে ক্যাচ ব্লকের ভিতরে থেকে কোনও লেনদেন করা হতে পারে?

Question

আমি এমএসডিএন সম্পর্কে TRY...CATCHএবং পড়ছি XACT_STATE।

এটিতে নিম্নলিখিত উদাহরণ রয়েছে যা কোনও লেনদেন প্রতিশ্রুতিবদ্ধ বা রোল ব্যাক করতে হবে কিনা তা নির্ধারণ করতে একটি কনস্ট্রাক্টের ব্লক ব্যবহার XACT_STATEকরে :CATCHTRY…CATCH

USE AdventureWorks2012;
GO

-- SET XACT_ABORT ON will render the transaction uncommittable
-- when the constraint violation occurs.
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRANSACTION;
        -- A FOREIGN KEY constraint exists on this table. This 
        -- statement will generate a constraint violation error.
        DELETE FROM Production.Product
            WHERE ProductID = 980;

    -- If the delete operation succeeds, commit the transaction. The CATCH
    -- block will not execute.
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    -- Test XACT_STATE for 0, 1, or -1.
    -- If 1, the transaction is committable.
    -- If -1, the transaction is uncommittable and should 
    --     be rolled back.
    -- XACT_STATE = 0 means there is no transaction and
    --     a commit or rollback operation would generate an error.

    -- Test whether the transaction is uncommittable.
    IF (XACT_STATE()) = -1
    BEGIN
        PRINT 'The transaction is in an uncommittable state.' +
              ' Rolling back transaction.'
        ROLLBACK TRANSACTION;
    END;

    -- Test whether the transaction is active and valid.
    IF (XACT_STATE()) = 1
    BEGIN
        PRINT 'The transaction is committable.' + 
              ' Committing transaction.'
        COMMIT TRANSACTION;   
    END;
END CATCH;
GO

আমি যা বুঝতে পারি না তা হ'ল কেন আমি যত্ন করে পরীক্ষা করব যে কী XACT_STATEফিরে আসে?

দয়া করে মনে রাখবেন, উদাহরণটিতে পতাকাটি XACT_ABORTসেট করা ONআছে।

যদি TRYব্লকের ভিতরে কোনও তীব্র ত্রুটি থাকে তবে নিয়ন্ত্রণটি প্রবেশ করবে CATCH। সুতরাং, যদি আমি এর ভিতরে থাকি তবে আমি CATCHজানি যে লেনদেনের কোনও সমস্যা হয়েছে এবং সত্যিই একমাত্র বুদ্ধিমান কাজ হ'ল এটিকে পিছনে ফেলা, তাই না?

তবে, এমএসডিএন-এর এই উদাহরণটি বোঝায় যে নিয়ন্ত্রণের মধ্যে প্রবেশের CATCHপরেও এমন কিছু ঘটনা ঘটতে পারে যা লেনদেনের প্রতিশ্রুতি দেয়। কেউ যখন কিছু ঘটতে পারে তখন এটি ব্যবহারিক উদাহরণ প্রদান করতে পারে, যখন তা বোঝা যায়?

আমি কি মামলা নিয়ন্ত্রণ ভিতরে পাশ করা যাবে না দেখতে পান CATCHএকটি লেনদেন যে প্রতিশ্রুতিবদ্ধ হতে পারে যখন XACT_ABORTসেট করা হয়ON ।

এমএসডিএন নিবন্ধটির SET XACT_ABORTএকটি উদাহরণ রয়েছে যখন কোনও লেনদেনের অভ্যন্তরে কিছু বিবৃতি সফলভাবে কার্যকর হয় এবং কিছু XACT_ABORTসেট হয়ে থাকে যখন সেট থাকে OFF, আমি তা বুঝতে পারি। তবে, SET XACT_ABORT ONকীভাবে এটি ঘটতে পারে যা ব্লকের XACT_STATE()ভিতরে 1 ফেরত দেয় CATCH?

প্রথমদিকে, আমি এই কোডটি এইভাবে লিখতাম:

USE AdventureWorks2012;
GO

-- SET XACT_ABORT ON will render the transaction uncommittable
-- when the constraint violation occurs.
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRANSACTION;
        -- A FOREIGN KEY constraint exists on this table. This 
        -- statement will generate a constraint violation error.
        DELETE FROM Production.Product
            WHERE ProductID = 980;

    -- If the delete operation succeeds, commit the transaction. The CATCH
    -- block will not execute.
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    -- Some severe problem with the transaction
    PRINT 'Rolling back transaction.';
    ROLLBACK TRANSACTION;
END CATCH;
GO

---

ম্যাক্স ভার্ননের একটি উত্তর আমলে নিয়ে আমি কোডটি এইভাবে লিখব। তিনি দেখিয়েছেন যে চেষ্টা করার আগে কোনও সক্রিয় লেনদেন আছে কিনা তা খতিয়ে দেখার অর্থ বোধ হয় ROLLBACK। এখনও, সঙ্গে ব্লক পারেন এ সব লেনদেন বা কোন লেনদেন দণ্ডপ্রাপ্ত করতে পারেন। সুতরাং, কোনও ক্ষেত্রে কিছুই করার নেই । আমি কি ভূল?SET XACT_ABORT ONCATCHCOMMIT

USE AdventureWorks2012;
GO

-- SET XACT_ABORT ON will render the transaction uncommittable
-- when the constraint violation occurs.
SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRANSACTION;
        -- A FOREIGN KEY constraint exists on this table. This 
        -- statement will generate a constraint violation error.
        DELETE FROM Production.Product
            WHERE ProductID = 980;

    -- If the delete operation succeeds, commit the transaction. The CATCH
    -- block will not execute.
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    -- Some severe problem with the transaction
    IF (XACT_STATE()) <> 0
    BEGIN
        -- There is still an active transaction that should be rolled back
        PRINT 'Rolling back transaction.';
        ROLLBACK TRANSACTION;
    END;

END CATCH;
GO

Answer 1

দেখা যাচ্ছে যে সেট করা থাকলে ব্লকের ভিতরে থেকে লেনদেন করা যায় না ।CATCHXACT_ABORTON

এমএসডিএন থেকে প্রাপ্ত উদাহরণটি কিছুটা বিভ্রান্তিকর, কারণ চেকটি সূচিত করে যা XACT_STATEকিছু ক্ষেত্রে 1 প্রদান করতে পারে এবং এটি COMMITলেনদেনের ক্ষেত্রেও সম্ভব হতে পারে ।

IF (XACT_STATE()) = 1
BEGIN
    PRINT 'The transaction is committable.' + 
          ' Committing transaction.'
    COMMIT TRANSACTION;   
END;

এটি সত্য নয়, যদি সেট করা থাকে তবে XACT_STATEকখনই 1 টি CATCHব্লকের ভিতরে ফিরে আসবে না ।XACT_ABORTON

দেখে মনে হয় যে এমএসডিএন নমুনা কোডটি সেটিং XACT_STATE()নির্বিশেষে মূলত ফাংশনটির ব্যবহার চিত্রিত করার জন্য বোঝানো হয়েছিল XACT_ABORT। স্যাম্পল কোডটি XACT_ABORTসেট ONও এন্ড উভয় ক্ষেত্রেই কাজ করার জন্য যথেষ্ট সাধারণ দেখায় OFF। এটা ঠিক যে XACT_ABORT = ONচেক IF (XACT_STATE()) = 1অপ্রয়োজনীয় হয়ে ওঠে।

---

এরল্যান্ড সোমমারস্কোগের এসকিউএল সার্ভারে ত্রুটি এবং লেনদেন পরিচালনার বিষয়ে নিবন্ধগুলির খুব ভাল সেট রয়েছে । ইন পার্ট 2 - ত্রুটি শ্রেণীবিভাগ তিনি একটি ব্যাপক টেবিল উপস্থাপন করে রাখে একসঙ্গে ত্রুটি সকল শ্রেণী-কিভাবে তারা SQL সার্ভার দ্বারা পরিচালিত এবং কিভাবে হয় TRY ... CATCHএবং XACT_ABORTআচরণ পরিবর্তন।

+-----------------------------+---------------------------++------------------------------+
|                             |     Without TRY-CATCH     ||        With TRY-CATCH        |
+-----------------------------+-------+-------+-----+-----++------------------+-----+-----+
|              SET XACT_ABORT |  OFF  |  ON   | OFF | ON  ||    ON or OFF     | OFF | ON  |
+-----------------------------+-------+-------+-----+-----++------------------+-----+-----+
| Class Name                  |    Aborts     |   Rolls   ||    Catchable     |   Dooms   |
|                             |               |   Back    ||                  |transaction|
+-----------------------------+-------+-------+-----+-----++------------------+-----+-----+
| Fatal errors                |  Connection   |    Yes    ||       No         |    n/a    |
| Batch-aborting              |     Batch     |    Yes    ||       Yes        |    Yes    |
| Batch-only aborting         |     Batch     | No  | Yes ||       Yes        | No  | Yes |
| Statement-terminating       | Stmnt | Batch | No  | Yes ||       Yes        | No  | Yes |
| Terminates nothing at all   |    Nothing    |    No     ||       Yes        | No  | Yes |
| Compilation: syntax errors  |  (Statement)  |    No     ||       Yes        | No  | Yes |
| Compilation: binding errors | Scope | Batch | No  | Yes || Outer scope only | No  | Yes |
| Compilation: optimisation   |     Batch     |    Yes    || Outer scope only |    Yes    |
| Attention signal            |     Batch     | No  | Yes ||       No         |    n/a    |
| Informational/warning msgs  |    Nothing    |    No     ||       No         |    n/a    |
| Uncatchable errors          |    Varying    |  Varying  ||       No         |    n/a    |
+-----------------------------+-------+-------+-----+-----++------------------+-----+-----+

সারণির শেষ কলামটি প্রশ্নের উত্তর দেয়। লেনদেনের সাথে TRY-CATCHএবং এর সাথে XACT_ABORT ONসমস্ত সম্ভাব্য ক্ষেত্রে ডুমড হয়।

প্রশ্নের ক্ষেত্রের বাইরে একটি নোট। এরল্যান্ড যেমন বলেছে, এই ধারাবাহিকতাটি সেট XACT_ABORTকরার অন্যতম কারণ ON:

আমি ইতিমধ্যে প্রস্তাব দিয়েছি যে আপনার সঞ্চিত পদ্ধতিতে কমান্ডটি অন্তর্ভুক্ত করা উচিত SET XACT_ABORT, NOCOUNT ON। আপনি যদি উপরের টেবিলটি লক্ষ্য করেন তবে আপনি দেখতে পাচ্ছেন যে XACT_ABORTকার্যকরভাবে এটির সাথে কিছু উচ্চ স্তরের ধারাবাহিকতা রয়েছে। উদাহরণস্বরূপ, লেনদেন সর্বদা নষ্ট হয়। নিম্নলিখিত, আমি অনেক উদাহরণ আমি কোথায় সেট দেখাবে XACT_ABORTকরতে OFF, আপনি কেন এই ডিফল্ট সেটিং এড়িয়ে চলা উচিত একটি বোঝার পেতে পারেন যাতে।

Answer 2

আমি এটি অন্যভাবে যোগাযোগ করতে হবে। XACT_ABORT_ONএকটি স্লেজ হাতুড়ি, আপনি আরও পরিমার্জিত পদ্ধতির ব্যবহার করতে পারেন, ব্যতিক্রম হ্যান্ডলিং এবং নেস্টেড লেনদেন দেখুন :

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

এই পদ্ধতির রোলব্যাক হবে, যখন সম্ভব হবে, কেবল টিআরওয়াই ব্লকের ভিতরে সম্পাদিত কাজগুলি, এবং ট্রাই ব্লকে প্রবেশের আগে রাজ্যে রাজ্য পুনরুদ্ধার করবে। এইভাবে আপনি জটিল প্রক্রিয়াজাতকরণ করতে পারেন, যেমন কোনও কার্সার পুনরায় করা, কোনও ত্রুটির ক্ষেত্রে ডাব্লু / ও সমস্ত কাজ হারিয়ে ফেলুন। একমাত্র ফিরে আসার বিষয়টি হ'ল লেনদেনের সেভপয়েন্টগুলি ব্যবহার করে, বিতরণকৃত লেনদেনের মতো সেভিং পয়েন্টগুলির সাথে সামঞ্জস্যপূর্ণ নয় এমন কোনও কিছু ব্যবহার থেকে আপনি নিষিদ্ধ হন।

Comments

আমি আপনার জবাবের প্রশংসা করি, তবে প্রশ্নটি আসলেই নয় যে আমাদের সেট XACT_ABORTকরা উচিত ONবা উচিত OFF।

— ভ্লাদিমির বারানভ

Answer 3

টিএল; ডিআর / এক্সিকিউটিভ সংক্ষিপ্তসার: প্রশ্নের এই অংশ সম্পর্কিত:

আমি কি মামলা নিয়ন্ত্রণ ভিতরে পাশ করা যাবে না দেখতে পান CATCHএকটি লেনদেন যে প্রতিশ্রুতিবদ্ধ হতে পারে যখন XACT_ABORTসেট করা হয়ON ।

আমি বেশ এখন এই পরীক্ষা একটি বিট কাজ করেছেন এবং আমি কোন ক্ষেত্রে যেখানে খুঁজে পাচ্ছি না XACT_STATE()আয় 1একটি ভেতরে CATCHব্লক যখন @@TRANCOUNT > 0 এবং এর অধিবেশন সম্পত্তি XACT_ABORTহল ON। এবং প্রকৃতপক্ষে, SET XACT_ABORT এর জন্য বর্তমান এমএসডিএন পৃষ্ঠা অনুসারে :

যখন SET XACT_ABORT চালু থাকে, কোনও লেনদেন-এসকিউএল বিবৃতি যদি রান-টাইম ত্রুটি উত্থাপন করে তবে পুরো লেনদেনটি বন্ধ হয়ে যায় এবং ফিরে আসে।

এই বিবৃতিটি আপনার জল্পনা এবং আমার অনুসন্ধানগুলির সাথে একমত বলে মনে হচ্ছে।

এমএসডিএন নিবন্ধটির SET XACT_ABORTএকটি উদাহরণ রয়েছে যখন কোনও লেনদেনের ভিতরে কিছু বিবৃতি সফলভাবে কার্যকর হয় এবং কিছু XACT_ABORTসেট হয়ে থাকে যখন সেট থাকে isOFF

এটা ঠিক যে, কিন্তু যে উদাহরণে বিবৃতি না একটি মধ্যে TRYব্লক। কোনও TRYব্লকের মধ্যে একই বিবৃতিগুলি ত্রুটির কারণ হয়ে যাওয়ার পরে কোনও বিবৃতি কার্যকর করার পরে আটকাতে পারে, তবে ধরে নেওয়া XACT_ABORTহয় OFF, যখন নিয়ন্ত্রণটি CATCHব্লকের কাছে পৌঁছে যায় তখন ট্রানজেকশনটি শারীরিকভাবে বৈধ যে পূর্ববর্তী সমস্ত পরিবর্তন ত্রুটি ছাড়াই ঘটেছিল did এবং প্রতিশ্রুতিবদ্ধ হতে পারে, যদি এটি ইচ্ছা হয়, বা সেগুলি ঘূর্ণিত হতে পারে। অন্যদিকে, যদি XACT_ABORTহয় ONতবে পূর্বের যে কোনও পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে ঘূর্ণিত হয় - এবং তারপরে আপনার পছন্দ হয়: ক) একটি জারি করুনROLLBACKলেনদেন ইতিমধ্যে বিয়োগ পুনরায় সেট @@TRANCOUNTকরতে ব্যর্থ হয়েছে 0, বা খ) একটি ত্রুটি পেয়ে যা বেশিরভাগই পরিস্থিতির একটি গ্রহণযোগ্যতা । পছন্দ খুব একটা না, তাই না?

এই ধাঁধাটির একটি সম্ভবত গুরুত্বপূর্ণ বিশদ যা এই ডকুমেন্টেশনের ক্ষেত্রে আপাত নয়, তা SET XACT_ABORTহ'ল এই সেশন সম্পত্তি, এবং সেই উদাহরণ কোডটিও এসকিউএল সার্ভার 2000 (ডকুমেন্টেশনগুলি সংস্করণগুলির মধ্যে প্রায় অভিন্ন) রয়েছে TRY...CATCHযা নির্মাণের পূর্বাভাস দিয়েছিল SQL সার্ভার 2005 সালে চালু করে ডকুমেন্টেশন এ খুঁজছি আবার এবং (উদাহরণস্বরূপ দিকে তাকিয়ে ছাড়াTRY...CATCH ), ব্যবহার XACT_ABORT ONকারণ একটি তাৎক্ষণিক লেনদেনের রোল-ব্যাক: সেখানে "uncommittable" (দয়া করে মনে রাখবেন কোন লেনদেন রাষ্ট্র এ কোনো উল্লেখ আছে যে সমস্ত " SET XACT_ABORTডকুমেন্টেশনে " আপত্তিজনক "লেনদেনের রাজ্য )।

আমি মনে করি যে এটি যুক্তিযুক্ত হওয়া যুক্তিযুক্ত:

1. TRY...CATCHএসকিউএল সার্ভার ২০০ the- এ কনস্ট্রাক্টের প্রবর্তন একটি নতুন ট্রানজেকশন স্টেটের (যেমন "আপত্তিহীন") এবং XACT_STATE()তথ্যটি পেতে ফাংশনের প্রয়োজনীয়তা তৈরি করেছিল।
2. নিম্নলিখিত কোনও দুটি সত্য হলে XACT_STATE()একটি CATCHব্লকে চেক করা সত্যই তা উপলব্ধি করতে পারে:
   1. XACT_ABORTহয় OFF(অন্যথায় XACT_STATE()সর্বদা ফিরে আসা উচিত -1এবং @@TRANCOUNTআপনার যা প্রয়োজন তা হ'ল )
   2. আপনি যুক্তি আছে CATCHশৃঙ্খল যদি কল নেস্টেড হয়, পরিবর্তন (ক তোলে আপ ব্লক, অথবা কোথাও COMMITবা এমনকি কোনো DML, DDL, ইত্যাদি বিবৃতি) পরিবর্তে একটি করছেন ROLLBACK। (এটি একটি অতি সাধারণ ব্যবহারের ক্ষেত্রে) ** দয়া করে সর্বদা XACT_STATE()পরিবর্তে মাইক্রোসফ্ট দ্বারা পরীক্ষা করার জন্য মাইক্রোসফ্ট কর্তৃক একটি অনানুষ্ঠানিক সুপারিশ সম্পর্কিত, আপডেট 3 বিভাগে নীচের অংশে নোটটি দেখুন @@TRANCOUNTএবং কেন পরীক্ষাগুলি দেখায় যে তাদের যুক্তিটি বেরিয়ে আসে না।
3. TRY...CATCHএসকিউএল সার্ভার ২০০ the- এ কনস্ট্রাক্টের প্রবর্তনটি বেশিরভাগ অংশে XACT_ABORT ONসেশন সম্পত্তিটি অচল করে দেয় কারণ এটি লেনদেনের উপর একটি বৃহত্তর ডিগ্রি নিয়ন্ত্রণের ব্যবস্থা করে (আপনার কাছে অন্তত বিকল্প রয়েছে COMMIT, যদি XACT_STATE()ফিরে না আসে তবে -1)।
   এই তাকান আরেকটি উপায় হল, পূর্বে SQL সার্ভার 2005 সালের , XACT_ABORT ONযখন একটি ত্রুটি ঘটেছে স্টপ প্রক্রিয়াকরণ একটি সহজ এবং নির্ভরযোগ্য উপায় প্রদান পরীক্ষণ তুলনায় @@ERRORপ্রতিটি বিবৃতি পরে।
4. এর জন্য ডকুমেন্টেশনের উদাহরণ কোডটি XACT_STATE()ভুল, বা সর্বোত্তম বিভ্রান্তিকর, এতে এটি XACT_STATE() = 1কখন রয়েছে XACT_ABORTতা পরীক্ষা করা দেখায় ON।

---

দীর্ঘ অংশ ;-)

হ্যাঁ, এমএসডিএন-তে সেই উদাহরণ কোডটি কিছুটা বিভ্রান্তিকর (এটিও দেখুন: @@ ট্রানট্যাক্ট (রোলব্যাক) বনাম XACT_STATE ) ;-)। আর, আমি এটা কারণ এটা হয় শো এমন কিছু বিষয় যা কোন অর্থে (কারণ আপনি জিজ্ঞাসা করা হয় প্রায়: আপনি এমনকি একটি "committable" লেনদেনের থাকতে পারে তোলে বিভ্রান্তিকর হয় মনে CATCHব্লক যখন XACT_ABORTহয় ON), অথবা এমনকি এটি সম্ভব, এটা এখনও একটি প্রযুক্তিগত সম্ভাবনার দিকে মনোনিবেশ করে যা খুব কম লোকই চাইবে বা প্রয়োজন হবে এবং যে কারণে এটির বেশি সম্ভাবনা রয়েছে তার কারণটি উপেক্ষা করে।

TRY ব্লকের ভিতরে যদি তীব্র পর্যাপ্ত ত্রুটি থাকে তবে নিয়ন্ত্রণটি ক্যাচটিতে চলে যাবে। সুতরাং, আমি যদি ক্যাচের অভ্যন্তরে থাকি তবে আমি জানি যে লেনদেনের কোনও সমস্যা হয়েছে এবং সত্যই একমাত্র বুদ্ধিমানের কাজটি করার ক্ষেত্রে এটি আবার ঘুরিয়ে দেওয়া, তাই না?

আমি মনে করি যদি আমরা কিছু নির্দিষ্ট শব্দ এবং ধারণা দ্বারা বোঝানো হয় সে বিষয়ে আমরা একই পৃষ্ঠায় রয়েছি কিনা তা নিশ্চিত করে নিলে এটি সহায়তা করবে:

• "গুরুতর পর্যাপ্ত ত্রুটি": কেবল পরিষ্কার করার জন্য, ট্রাই ... ক্যাচ বেশিরভাগ ত্রুটি জাল করবে। যা ধরা পড়বে না তার তালিকা সেই লিঙ্কযুক্ত এমএসডিএন পৃষ্ঠায় "একটি ট্রাই দ্বারা আটকানো ত্রুটি… ক্যাচ কনস্ট্রাক্ট" বিভাগের অধীনে তালিকাভুক্ত করা হয়েছে।

• "আমি যদি ক্যাচের অভ্যন্তরে থাকি তবে আমি জানি যে লেনদেনের কোনও সমস্যা হয়েছে" (এম ফ্যাস যোগ করা হয়েছে): যদি "লেনদেন" বলতে আপনার অর্থ লজিক্যাল ইউনিটকে আপনার দ্বারা সুস্পষ্ট লেনদেনে বিভাজনকে দলবদ্ধ করে নির্ধারিত করে থাকে, তবে সম্ভবত হ্যাঁ আমি মনে করি আমাদের বেশিরভাগ ডিবি লোকেরা সম্মত হবেন যে রোলিং ব্যাক হ'ল "একমাত্র বুদ্ধিমান কাজ" যেহেতু আমরা কীভাবে এবং কেন স্পষ্ট লেনদেন ব্যবহার করি এবং কী কী পদক্ষেপগুলি পরমাণু ইউনিট গঠন করা উচিত তা সম্পর্কে আমাদের একই মতামত থাকতে পারে কাজ এর.

  তবে, যদি আপনি বোঝাতে চান কাজের প্রকৃত ইউনিটগুলি যা সুস্পষ্ট লেনদেনের জন্য দলবদ্ধ করা হচ্ছে, তবে না, আপনি জানেন না যে লেনদেনে নিজেই কোনও সমস্যা হয়েছে। আপনি কেবল জানেন যে সুস্পষ্টভাবে সংজ্ঞায়িত লেনদেনের মধ্যে সম্পাদিত একটি বিবৃতি একটি ত্রুটি বাড়িয়েছে। তবে এটি কোনও ডিএমএল বা ডিডিএল বিবৃতি নাও হতে পারে। এমনকি এটি ডিএমএল বিবৃতি হলেও, লেনদেনটি নিজেই দায়বদ্ধ হতে পারে।

উপরোক্ত দুটি পয়েন্ট দেওয়া, আমাদের সম্ভবত "যে" প্রতিশ্রুতিবদ্ধ "করতে পারে না এবং যেটি আপনি করতে চান না" এর মধ্যে "লেনদেনের মধ্যে একটি পার্থক্য আঁকতে হবে।

যখন XACT_STATE()আয় একটি 1, তার মানে তাদের লেনদেন "committable" হয়, তাহলে আপনি মধ্যে একটা চয়েস আছে COMMITবা ROLLBACK। আপনি এটি প্রতিশ্রুতিবদ্ধ হতে নাও চান , তবে যদি কোনও কারণে-যেমন-উদাহরণ-সহকারে কঠোর-এমনকি-সমালোচনার জন্য-আসতে থাকে তবে কমপক্ষে আপনি করতে পারেন কারণ লেনদেনের কিছু অংশ সফলতার সাথে সম্পন্ন হয়েছিল।

তবে যখন XACT_STATE()কোনও ফেরত দেয় -1, তখন আপনার সত্যিকারের প্রয়োজন ROLLBACKকারণ লেনদেনের কিছু অংশ খারাপ অবস্থায় চলে যায়। এখন, আমি একমত যে যদি নিয়ন্ত্রণটি ক্যাচ ব্লকে পৌঁছে দেওয়া হয়, তবে এটি কেবলমাত্র পরীক্ষা করা যথেষ্ট পরিমাণে বোঝা যায় @@TRANCOUNT, কারণ আপনি যদি লেনদেন করতে পারেন, কেন আপনি চান?

আপনি যদি উদাহরণের শীর্ষে লক্ষ্য করেন তবে XACT_ABORT ONকিছু কিছু পরিবর্তন করে। আপনি একটি নিয়মিত ত্রুটি থাকতে পারে, করছেন পরে BEGIN TRANবুঝতে পারা ব্লক নিয়ন্ত্রণ পাস হবে যখন XACT_ABORTহয় OFFএবং XACT_STATE () ফিরে আসবে 1। তবে, যদি XACT_ABORT হয় ONতবে কোনও 'ত্রুটি ত্রুটির জন্য লেনদেন "বাতিল" (অর্থাত অবৈধ) হয় এবং তারপরে XACT_STATE()ফিরে আসবে -1। এই ক্ষেত্রে, এটা চেক করতে বেহুদা মনে হয় XACT_STATE()মধ্যে CATCHব্লক হিসাবে এটা সবসময় একটি আসতে বলে মনে হয় -1যখন XACT_ABORTহয় ON।

তাহলে কি XACT_STATE()জন্য? কিছু ক্লু হ'ল:

• TRY...CATCH"আপত্তিজনক লেনদেন এবং XACT_STATE" বিভাগের অধীনে এমএসডিএন পৃষ্ঠাটি বলে:

  সাধারণত একটি ট্রিওয়াই ব্লকের বাইরে লেনদেন শেষ করে এমন একটি ত্রুটি যখন একটি ট্রাই ব্লকের ভিতরে ত্রুটি ঘটে তখন একটি লেনদেনটিকে একটি দ্বিধাবিহীন অবস্থায় প্রবেশ করে।

• "মন্তব্যগুলি" বিভাগের অধীনে SET XACT_ABORT এর জন্য এমএসডিএন পৃষ্ঠাটি বলেছেন:

  যখন এসইটি XACT_ABORT বন্ধ থাকে, কিছু ক্ষেত্রে কেবল ত্রুটি উত্থাপিত ট্রান্সঅ্যাক্ট-এসকিউএল বিবৃতি আবার ঘুরিয়ে দেওয়া হয় এবং লেনদেন প্রক্রিয়াজাতকরণ অব্যাহত থাকে।

  এবং:

  এসএকিউএল সার্ভার সহ বেশিরভাগ ওএলডি ডিবি সরবরাহকারীদের বিরুদ্ধে একটি স্পষ্ট বা স্পষ্ট লেনদেনের ক্ষেত্রে ডেটা সংশোধন বিবরণের জন্য XACT_ABORT টি চালু থাকতে হবে।

• "মন্তব্যগুলি" বিভাগের অধীনে শুরু হওয়া বিগইন ট্রান্সএকশনের জন্য এমএসডিএন পৃষ্ঠাটি বলেছেন:

  বিগইন ট্রান্সএকশন বিবৃতি দিয়ে শুরু হওয়া স্থানীয় লেনদেন বিতরণ লেনদেনে বাড়ানো হয় যদি বিবৃতিটি প্রতিশ্রুতিবদ্ধ বা ফিরে ঘোরানোর আগে নিম্নলিখিত ক্রিয়া সম্পাদিত হয়:

  • সংযুক্ত সার্ভারে একটি দূরবর্তী টেবিলের উল্লেখ করে একটি INSERT, মোছা বা আপডেটের বিবৃতি কার্যকর করা হয়। সংযুক্ত সার্ভারটি অ্যাক্সেস করতে ব্যবহৃত OLE DB সরবরাহকারী ITransactionJoin ইন্টারফেস সমর্থন না করে যদি INSERT, আপডেট, বা মোছার বিবৃতি ব্যর্থ হয়।

সর্বাধিক প্রযোজ্য ব্যবহারটি লিঙ্কযুক্ত সার্ভারের ডিএমএল স্টেটমেন্টের প্রসঙ্গে রয়েছে বলে মনে হয়। এবং আমি বিশ্বাস করি যে আমি নিজেই এটির মধ্যে বেশ কয়েক বছর আগে চলে এসেছি। আমি সমস্ত বিবরণ মনে রাখিনা, তবে এটি রিমোট সার্ভারটি উপলব্ধ না হওয়ার সাথে কিছু করার ছিল এবং কোনও কারণে, ত্রুটিটি ট্রাই ব্লকের মধ্যে ধরা পড়েনি এবং কখনও ক্যাশে পাঠানো হয়নি এবং তাই এটি হয়েছিল did একটি কমিটি যখন এটি না করা উচিত। অবশ্যই, যে পারে না বলে একটা ব্যাপার আছে হয়েছে XACT_ABORTসেট ONবদলে চেক করতে ব্যর্থ XACT_STATE(), অথবা সম্ভবত উভয়। এবং আমি এমন কিছু পড়ার কথা মনে করি যা বলেছিল যে আপনি যদি লিঙ্কযুক্ত সার্ভার এবং / অথবা বিতরণ লেনদেন ব্যবহার করেন তবে আপনাকে ব্যবহার করার প্রয়োজন ছিল XACT_ABORT ONএবং / অথবা XACT_STATE(), তবে আমি এখন এই নথিটি খুঁজে পাচ্ছি না। যদি আমি এটি খুঁজে পাই তবে আমি লিঙ্কটি সহ এটি আপডেট করব।

তবুও, আমি বেশ কয়েকটি জিনিস চেষ্টা করে দেখেছি এবং প্রতিবেদন করার সাথে সাথে ব্লকের XACT_ABORT ONনিয়ন্ত্রণ ও এমন দৃশ্যের সন্ধান করতে অক্ষম ।CATCHXACT_STATE()1

XACT_ABORTএর মানটির প্রভাব দেখতে এই উদাহরণগুলি ব্যবহার করে দেখুন XACT_STATE():

SET XACT_ABORT OFF;

BEGIN TRY
    BEGIN TRAN;

    SELECT 1/0 AS [DivideByZero]; -- error, yo!

    COMMIT TRAN;
END TRY
BEGIN CATCH
    SELECT @@TRANCOUNT AS [@@TRANCOUNT],
            XACT_STATE() AS [XactState],
            ERROR_MESSAGE() AS [ErrorMessage]

    IF (@@TRANCOUNT > 0)
    BEGIN
        ROLLBACK;
    END;
END CATCH;

GO ------------------------------------------------

SET XACT_ABORT ON;

BEGIN TRY
    BEGIN TRAN;

    SELECT 1/0 AS [DivideByZero]; -- error, yo!

    COMMIT TRAN;
END TRY
BEGIN CATCH
    SELECT @@TRANCOUNT AS [@@TRANCOUNT],
            XACT_STATE() AS [XactState],
            ERROR_MESSAGE() AS [ErrorMessage]

    IF (@@TRANCOUNT > 0)
    BEGIN
        ROLLBACK;
    END;
END CATCH;

GO ------------------------------------------------

SET XACT_ABORT ON;

BEGIN TRY
    SELECT 1/0 AS [DivideByZero]; -- error, yo!
END TRY
BEGIN CATCH
    SELECT @@TRANCOUNT AS [@@TRANCOUNT],
            XACT_STATE() AS [XactState],
            ERROR_MESSAGE() AS [ErrorMessage]
END CATCH;

---

হালনাগাদ

মূল প্রশ্নের অংশ না হলেও, এই উত্তরের এই মন্তব্যের ভিত্তিতে:

আমি ত্রুটি ও লেনদেন পরিচালনার বিষয়ে এরল্যান্ডের নিবন্ধগুলি পড়ছি যেখানে তিনি বলেছেন যে উত্তরাধিকারগত কারণে XACT_ABORTমূলত এটি হয় OFFএবং সাধারণত আমাদের এটি সেট করা উচিত ON।
...
"... আপনি যদি প্রস্তাবটি অনুসরণ করেন এবং SET XACT_ABORT চালু রেখে যান তবে লেনদেন সর্বদা সর্বনাশ হয়ে যায়।"

XACT_ABORT ONসর্বত্র ব্যবহার করার আগে , আমি প্রশ্ন করব: এখানে ঠিক কী অর্জন করা হচ্ছে? আমি এটি করা প্রয়োজন বলে মনে করি না এবং সাধারণত প্রয়োজন হয় তবে আপনার এটি ব্যবহার করা উচিত এমন পরামর্শও দিয়েছেন। ROLLBACKআপনি @ রিমাসের উত্তরে দেখানো টেম্পলেট ব্যবহার করে আপনি সহজেই হ্যান্ডেল করতে চান বা না চান , বা যেটি আমি বছরের পর বছর ধরে ব্যবহার করছি যা মূলত একই জিনিস তবে সেভ পয়েন্ট ছাড়াই, এই উত্তরে দেখানো হয়েছে (যা কোনটি নেস্টেড কলগুলি পরিচালনা করে):

আমাদের কি সি # কোড এবং সেই সাথে সঞ্চিত পদ্ধতিতে লেনদেন পরিচালনা করতে হবে?

---

আপডেট 2

আমি এই মুহূর্তে একটি ছোট্ট নেট নেট কনসোল অ্যাপ তৈরি করে, কোনও অ্যাপ্লিকেশন কার্যকর করার আগে অ্যাপ্লিকেশন স্তরে একটি লেনদেন তৈরি SqlCommandকরে (যেমন মাধ্যমে using (SqlTransaction _Tran = _Connection.BeginTransaction()) { ...), পাশাপাশি কেবল বিবৃতি না দিয়ে ব্যাচ-অ্যাওর্টিং ত্রুটি ব্যবহার করে আমি আরও কিছু পরীক্ষা করেছি I -বোর্টিং ত্রুটি, এবং এটি খুঁজে পেয়েছে:

1. একটি "আপত্তিজনক" লেনদেন হ'ল এটি বেশিরভাগ অংশে ইতিমধ্যে ঘুরে ফিরে গেছে (পরিবর্তনগুলি পূর্বাবস্থায় ফিরে এসেছে) তবে @@TRANCOUNTএখনও 0% is
2. যখন আপনার একটি "আপত্তিজনক" লেনদেন হয় আপনি লেনদেনটি "আপত্তিজনক" COMMITবলে ত্রুটি করে এমনটি উত্পন্ন করতে পারবেন না । আপনি এটিকে উপেক্ষাও করতে পারবেন না বা কিছুই করবেন না কারণ ত্রুটি উত্পন্ন হবে যখন ব্যাচ শেষ করে বলেছিল যে ব্যাচটি দীর্ঘকালীন, আপত্তিজনক লেনদেনের মাধ্যমে সম্পন্ন হয়েছে এবং এটি আবার ঘুরিয়ে দেওয়া হবে (সুতরাং, যদি এটি যাইহোক অটো-রোল-ব্যাক হবে, ত্রুটি ছুড়ে কেন বিরক্ত করবেন?)। সুতরাং আপনাকে অবশ্যই একটি স্পষ্ট ইস্যু করতে হবেROLLBACK , সম্ভবত তাড়াতাড়ি CATCHব্লকে নয়, তবে ব্যাচটি শেষ হওয়ার আগেই।
3. কোন TRY...CATCHকনস্ট্রাক্টে, কখন XACT_ABORTহয় OFF, ত্রুটিগুলি যা লেনদেনের স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায় যদি সেগুলি কোনও TRYব্লকের বাইরে ঘটে থাকে যেমন ব্যাচ-গর্ভপাত ত্রুটিগুলি, কাজটিকে পূর্বাবস্থায় ফিরিয়ে দেবে তবে ট্রানসেকশনটি সমাপ্ত করবে না, এটিকে "আপত্তিজনক" হিসাবে রেখে যাবে। ROLLBACKলেনদেন বন্ধ করার জন্য একটি ইস্যু করা আরও আনুষ্ঠানিকতার প্রয়োজন, তবে ইতিমধ্যে কাজটি রোলড-ব্যাক হয়েছে।
4. কখন XACT_ABORTহয় ON, বেশিরভাগ ত্রুটি ব্যাচ-গর্ভপাত হিসাবে কাজ করে এবং তাই সরাসরি বুলেট পয়েন্টে উপরে বর্ণিত হিসাবে আচরণ করে (# 3)।
5. XACT_STATE(), ত্রুটির সময়ে কোনও সক্রিয় লেনদেন থাকলে কমপক্ষে কোনও CATCHব্লকে, -1ব্যাচ-অ্যাওর্টিং ত্রুটির জন্য একটি প্রদর্শন করবে ।
6. XACT_STATE()1কোনও সক্রিয় লেনদেন না থাকলেও কখনও কখনও ফিরে আসে । যদি @@SPID(অন্যদের মধ্যে) SELECTতালিকায় থাকে XACT_STATE()তবে XACT_STATE()সক্রিয় লেনদেন না থাকলে 1 ফিরে আসবে। এই আচরণটি এসকিউএল সার্ভার ২০১২ সালে শুরু হয়েছিল এবং এটি ২০১৪-তে উপস্থিত রয়েছে, তবে আমি ২০১ on সালে পরীক্ষা করিনি।

উপরের বিষয়গুলি মাথায় রেখে:

• প্রদত্ত পয়েন্ট # 4 এবং # 5, সবচেয়ে (বা সকলের?) যেহেতু ত্রুটি একটি লেনদেন "uncommitable" রেন্ডার হবে, এটি সম্পূর্ণরূপে চেক করতে অর্থহীন বলে মনে হয় XACT_STATE()এ CATCHব্লক যখন XACT_ABORTহয় ONফিরে সবসময় হতে হবে মান যেহেতু -1।
• পরীক্ষা করা হচ্ছে XACT_STATE()এ CATCHব্লক যখন XACT_ABORTহয় OFFআরো ইন্দ্রিয় তোলে কারণ ফেরত মান অন্তত কিছু প্রকরণ থাকবে যেহেতু এটি ফিরে আসবে 1বিবৃতি-গর্ভপাত ত্রুটির জন্য। তবে, আপনি যদি আমাদের বেশিরভাগের মতো কোড করেন তবে এই পার্থক্যটি অর্থহীন, যেহেতু আপনি ROLLBACKকোনও ত্রুটি ঘটেছে এই কারণে আপনি যেভাবেই কল করবেন ।
• যদি আপনি এমন কোনও পরিস্থিতি খুঁজে COMMITপান যা CATCHব্লকটিতে ওয়ারেন্ট জারি করে , তবে এর মানটি পরীক্ষা করে দেখুন XACT_STATE()এবং নিশ্চিত হন SET XACT_ABORT OFF;।
• XACT_ABORT ONমনে হচ্ছে TRY...CATCHনির্মাণের জন্য কোনও লাভ নেই ।
• আমি এমন কোনও দৃশ্য খুঁজে পাই না যেখানে চেকিং XACT_STATE()কেবল চেকিংয়ের মাধ্যমে অর্থবহ সুবিধা দেয় @@TRANCOUNT।
• যখন এমন কোনও ব্লক যখন XACT_STATE()ফিরে আসে তখন আমি এমন কোনও দৃশ্যের সন্ধান করতে পারি না । আমি মনে করি এটি একটি ডকুমেন্টেশন ত্রুটি।1CATCHXACT_ABORTON
• হ্যাঁ, আপনি এমন কোনও লেনদেনের রোল-ব্যাক করতে পারেন যা আপনি স্পষ্টভাবে শুরু করেননি। এবং ব্যবহারের প্রসঙ্গে XACT_ABORT ON, এটি একটি মূল বিন্দু যেহেতু একটি TRYব্লকে ঘটে যাওয়া ত্রুটিটি স্বয়ংক্রিয়ভাবে পরিবর্তনগুলি রোল-ব্যাক করবে।
• সম্পূর্ণ লেনদেন স্বয়ংক্রিয়ভাবে বাতিল না TRY...CATCHকরার ফলে এই কনস্ট্রাক্টের সুবিধা রয়েছে XACT_ABORT ONএবং তাই লেনদেনের (যতক্ষণ না XACT_STATE()প্রত্যাবর্তনের সময় পর্যন্ত 1) প্রতিশ্রুতিবদ্ধ হতে দেওয়া হয় (এমনকি এটি প্রান্তের ক্ষেত্রে হলেও)।

উদাহরণ XACT_STATE()ফিরে -1যখন XACT_ABORTহয় OFF:

SET XACT_ABORT OFF;

BEGIN TRY
    BEGIN TRAN;

    SELECT CONVERT(INT, 'g') AS [ConversionError];

    COMMIT TRAN;
END TRY
BEGIN CATCH
    DECLARE @State INT;
    SET @State = XACT_STATE();
    SELECT @@TRANCOUNT AS [@@TRANCOUNT],
            @State AS [XactState],
            ERROR_MESSAGE() AS [ErrorMessage];

    IF (@@TRANCOUNT > 0)
    BEGIN
        SELECT 'Rollin back...' AS [Transaction];
        ROLLBACK;
    END;
END CATCH;

---

আপডেট 3

আপডেট 2 বিভাগের আইটেম # 6 এর সাথে সম্পর্কিত ( XACT_STATE()যেমন কোনও সক্রিয় লেনদেন নেই তখন ফিরে আসা সম্ভব ভুল মান ):

• বিজোড় / ভ্রান্ত আচরণটি এসকিউএল সার্ভার ২০১২ সালে শুরু হয়েছিল (এখনও পর্যন্ত ২০১২ এসপি 2 এবং ২০১৪ এসপি 1 এর বিপরীতে পরীক্ষিত)
• এসকিউএল সার্ভার সংস্করণে ২০০ 2008, ২০০৮ এবং ২০০৮ আর ২- XACT_STATE()এ ট্রিগার বা INSERT...EXECপরিস্থিতি ব্যবহারের সময় প্রত্যাশিত মানগুলির প্রতিবেদন করা হয়নি : লেনদেনটি ডুমড হয়েছে কিনা তা নির্ধারণের জন্য xact_state () নির্ভরযোগ্যভাবে ব্যবহার করা যায় না । যাইহোক, এই 3 সংস্করণে (আমি শুধুমাত্র 2008 R2 হলো উপর পরীক্ষা) এ, XACT_STATE()নেই না ভুল রিপোর্ট 1যখন একটি ব্যবহৃত SELECTসঙ্গে @@SPID।

• এখানে উল্লিখিত আচরণের বিরুদ্ধে একটি কানেক্ট বাগটি দায়ের করা হয়েছে তবে এটি "ডিজাইন দ্বারা" হিসাবে বন্ধ রয়েছে: এক্সএসিএসএসটিএটি () এসকিউএল 2012 এ একটি ভুল লেনদেনের অবস্থা ফিরিয়ে দিতে পারে । তবে, ডিএমভি থেকে বাছাই করার সময় পরীক্ষাটি করা হয়েছিল এবং এটি সিদ্ধান্তে পৌঁছেছিল যে এটি করার ফলে স্বাভাবিকভাবেই একটি সিস্টেম উত্পন্ন লেনদেন হবে, কমপক্ষে কিছু ডিএমভিতে for এমএসের চূড়ান্ত জবাবে এটিও বলা হয়েছিল যে:

  মনে রাখবেন যে কোনও আইএফ স্টেটমেন্ট এবং এফআরএম ছাড়াই একটি নির্বাচন করুন, কোনও লেনদেন শুরু করবেন না।
  উদাহরণস্বরূপ, আপনার যদি পূর্বের বিদ্যমান লেনদেন না থাকে তবে SELECT XACT_STATE () চালনা করলে 0 ফিরে আসবে।

  নিম্নলিখিত বিবৃতি দিয়ে এই বিবৃতিগুলি ভুল:

  SELECT @@TRANCOUNT AS [TRANCOUNT], XACT_STATE() AS [XACT_STATE], @@SPID AS [SPID];
  GO
  DECLARE @SPID INT;
  SET @SPID = @@SPID;
  SELECT @@TRANCOUNT AS [TRANCOUNT], XACT_STATE() AS [XACT_STATE], @SPID AS [SPID];
  GO

• অতএব, নতুন সংযুক্ত ত্রুটি:
  কিছু সিস্টেম ভেরিয়েবলের সাথে SEF এ ব্যবহৃত হয় তবে FROM ধারা ছাড়াই XACT_STATE () 1 প্রদান করে

অনুগ্রহ করে নোট করুন যে "XACT_STATE () এ এসকিউএল ২০১২-তে একটি ভুল লেনদেনের অবস্থা ফিরিয়ে দিতে পারে" উপরের সাথে সংযুক্ত আইটেমটি সরাসরি সংযুক্ত করুন, মাইক্রোসফ্ট (ভাল, একটি প্রতিনিধি) বলেছেন:

@@ ট্রান্সকাউন্ট বিগিন ট্রান বিবৃতিগুলির সংখ্যা প্রদান করে। এটি সক্রিয় লেনদেন আছে কিনা তা নির্ভরযোগ্য সূচক নয়। সক্রিয় অটোকোমিট লেনদেন থাকলে XACT_STATE () এছাড়াও 1 প্রদান করে এবং এইভাবে সক্রিয় লেনদেন আছে কিনা তা আরও নির্ভরযোগ্য সূচক।

তবে আমি বিশ্বাস না করার কোনও কারণ খুঁজে পাচ্ছি না @@TRANCOUNT। নিম্নলিখিত পরীক্ষাটি দেখায় যে @@TRANCOUNTপ্রকৃতপক্ষে 1একটি স্ব-প্রতিশ্রুতিবদ্ধ লেনদেনে ফিরে আসে :

--- begin setup
GO
CREATE PROCEDURE #TransactionInfo AS
SET NOCOUNT ON;
SELECT @@TRANCOUNT AS [TranCount],
       XACT_STATE() AS [XactState];
GO
--- end setup

DECLARE @Test TABLE (TranCount INT, XactState INT);

SELECT * FROM @Test; -- no rows

EXEC #TransactionInfo; -- 0 for both fields

INSERT INTO @Test (TranCount, XactState)
    EXEC #TransactionInfo;

SELECT * FROM @Test; -- 1 row; 1 for both fields

আমি একটি ট্রিগার দিয়ে একটি বাস্তব টেবিলেও পরীক্ষা করেছিলাম এবং স্পষ্টভাবে কোনও ট্রানজেকশন শুরু না হওয়া সত্ত্বেও @@TRANCOUNTট্রিগারটির মধ্যে সঠিকভাবে রিপোর্ট 1করেছিলাম।

Answer 4

ডিফেন্সিভ প্রোগ্রামিংয়ের জন্য আপনাকে এমন কোড লিখতে হবে যা যতটা সম্ভব পরিচিত রাজ্য পরিচালনা করে, যার ফলে বাগের সম্ভাবনা হ্রাস পায় reducing

কোনও রোলব্যাক কার্যকর করা যায় কিনা তা নির্ধারণ করার জন্য XACT_STATE () পরীক্ষা করা সহজভাবে অনুশীলন। অন্ধভাবে রোলব্যাক চেষ্টা করার অর্থ আপনি অসাবধানতাবশত আপনার ট্রাই ... ক্যাচ এর ভিতরে একটি ত্রুটি ঘটাতে পারেন।

কোনও উপায়ে কোনও রোলব্যাক ব্যর্থ হতে পারে ... ক্যাচ হ'ল যদি আপনি স্পষ্টভাবে লেনদেন শুরু না করেন। কোড ব্লক অনুলিপি করা এবং আটকানো সহজেই এর কারণ হতে পারে।

Comments

উত্তর দেওয়ার জন্য আপনাকে ধন্যবাদ. আমি কেবল এমন কোনও ক্ষেত্রেই ভাবতে পারি না যখন সাধারণ ROLLBACKঅভ্যন্তরের অভ্যন্তরে কাজ করে না CATCHএবং আপনি একটি ভাল উদাহরণ দিয়েছেন। আমার ধারণা, যদি নেস্টেড লেনদেন এবং নিজের সাথে নেস্টেড স্টোরেজ প্রক্রিয়া TRY ... CATCH ... ROLLBACKজড়িত থাকে তবে এটি দ্রুত অগোছালো হয়ে উঠতে পারে ।

— ভ্লাদিমির বড়ানভ

তবুও, আমি এটির প্রশংসা করব, যদি আপনি দ্বিতীয় উত্তরটি সম্পর্কে আপনার উত্তরটি প্রসারিত IF (XACT_STATE()) = 1 COMMIT TRANSACTION; করতে পারেন - আমরা কীভাবে CATCHপ্রতিশ্রুতিবদ্ধ লেনদেনের মাধ্যমে ব্লকের অভ্যন্তরে শেষ করতে পারি ? আমি এর ভিতরে থেকে কিছু (সম্ভাব্য) আবর্জনা ফেলার সাহস করব না CATCH। আমার যুক্তিটি হ'ল: আমরা যদি CATCHকিছু ভিতরে থাকি তবে ভুল হয়ে যায়, আমি ডাটাবেসের স্থিতিতে বিশ্বাস করতে পারি না, তাই ROLLBACKআমরা যা পেয়েছি তা আরও ভাল করতে পারি।

— ভ্লাদিমির বড়ানভ