3 টি সঞ্চিত প্রক্রিয়া যখন একটি সঞ্চিত পদ্ধতি থেকে শুরু হয় তখন কীভাবে রোলব্যাক করবেন


23

আমার কাছে একটি সঞ্চিত প্রক্রিয়া রয়েছে যা কেবলমাত্র তাদের মধ্যে 3 টি সঞ্চিত প্রক্রিয়া চালায়। মাস্টার এসপি সফল হলে আমি কেবলমাত্র 1 টি প্যারামিটার সঞ্চয় করতে ব্যবহার করছি।

যদি প্রথম সঞ্চিত পদ্ধতিটি মাস্টার সঞ্চিত পদ্ধতিতে সূক্ষ্মভাবে কাজ করে তবে ২ য় সঞ্চিত পদ্ধতি ব্যর্থ হয়, তবে এটি স্বয়ংক্রিয়ভাবে মাস্টার এসপিতে সমস্ত এসপির পিছনে ফিরে যাবে বা আমাকে কিছু আদেশ দিতে হবে?

আমার পদ্ধতিটি এখানে:

CREATE PROCEDURE [dbo].[spSavesomename] 
    -- Add the parameters for the stored procedure here

    @successful bit = null output
AS
BEGIN
begin transaction createSavebillinginvoice
    begin Try
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

   BEGIN 

   EXEC [dbo].[spNewBilling1]

   END

   BEGIN 

   EXEC [dbo].[spNewBilling2]

   END

   BEGIN 

   EXEC [dbo].[spNewBilling3]

   END 

   set @successful  = 1

   end Try

    begin Catch
        rollback transaction createSavesomename
        insert into dbo.tblErrorMessage(spName, errorMessage, systemDate) 
             values ('spSavesomename', ERROR_MESSAGE(), getdate())

        return
    end Catch
commit transaction createSavesomename
return
END

GO

যদি spNewBilling3কোনও ত্রুটি নিক্ষেপ করে তবে আপনি ফিরে রোল করতে চান না spNewBilling2বা spNewBilling1, তবে কেবল এখান [begin|rollback|commit] transaction createSavebillinginvoiceথেকে সরিয়ে দিন spSavesomename
মাইক

উত্তর:


56

শুধুমাত্র প্রশ্নে দেখানো কোডটি দেওয়া, এবং তিনটি সাব-procs মধ্যে যে কেউ অভিমানী কোনো স্পষ্ট লেনদেন হ্যান্ডলিং, তাহলে হ্যাঁ, এই তিনটি সাব-procs কোন একটি ত্রুটি ধরা পড়বে এবং ROLLBACKCATCHব্লক ফিরে সব গুটিয়ে রাখবে কাজের।

তবে লেনদেন সম্পর্কে কিছু জিনিস নোট করার জন্য এখানে রয়েছে (কমপক্ষে এসকিউএল সার্ভারে):

  • আপনি যতবার কল করেন না কেন কেবলমাত্র একটি আসল লেনদেন হয় (প্রথমটি)BEGIN TRAN

    • আপনি একটি লেনদেন নাম করতে পারেন (যেমন তুমি এখানে কাজ করেছেন) এবং যে নাম লগ উপস্থিত হবে, কিন্তু শুধুমাত্র প্রথম / বাইরের-পূর্বের লেনদেনের জন্য অর্থ নেমিং (কারণ আবার, প্রথম এক লেনদেনের)।
    • প্রতিবার যখন আপনি কল করেছেন, নাম দেওয়া BEGIN TRANহোক বা না হোক, লেনদেনের কাউন্টারটি 1 দ্বারা বাড়ানো হয়েছে।
    • আপনি বর্তমান স্তরটি করে দেখতে পারেন SELECT @@TRANCOUNT;
    • কোন COMMITইস্যু যখন কমান্ড @@TRANCOUNTউপরে 2 এ বা বেশি কমাতে, একটি সময়ে এক লেনদেন পাল্টা কিছুই করতে।
    • কোনওটি COMMITজারি না হওয়া অবধি প্রতিশ্রুতিবদ্ধ হয় না যখন @@TRANCOUNTথাকে1
    • কেবলমাত্র উপরের তথ্যগুলি সুস্পষ্টভাবে নির্দেশ করে না: লেনদেনের স্তর নির্বিশেষে, লেনদেনের আসল বাসা নেই।
  • পয়েন্টগুলি সংরক্ষণ করুন পূর্বাবস্থায় ফিরে আসা যায় এমন লেনদেনের মধ্যে কাজের একটি উপসেট তৈরি করার অনুমতি দেয় ।

    • SAVE TRAN {save_point_name}কমান্ডের মাধ্যমে সেভ পয়েন্টগুলি তৈরি করা / চিহ্নিত করা হয়
    • পয়েন্টগুলি সংরক্ষণ করুন কাজের সাবসেটের সূচনা চিহ্নিত করুন যা পুরো লেনদেনকে পিছনে না ফেলেই পূর্বাবস্থায় ফিরে আসতে পারে।
    • সেভ পয়েন্টের নামগুলি অনন্য হওয়ার দরকার নেই, তবে একই নাম ব্যবহারের পরেও একাধিকবার পৃথক সেভ পয়েন্ট তৈরি হয়।
    • সংরক্ষণ করুন পয়েন্ট করতে নেস্টেড হবে না।
    • সংরক্ষণের পয়েন্টগুলি প্রতিশ্রুতিবদ্ধ হতে পারে না।
    • সেভ পয়েন্টগুলি এর মাধ্যমে পূর্বাবস্থায় ফেরা যায় ROLLBACK {save_point_name}। (এই নীচে আরও)
    • একটি সেভ পয়েন্টকে রোলিং করা সবচেয়ে সাম্প্রতিক কলের পরে ঘটে যাওয়া যে কোনও কাজকে পূর্বাবস্থায় ফিরিয়ে আনবে SAVE TRAN {save_point_name}, রোল-ব্যাক তৈরির পরে তৈরি হওয়া কোনও সেভ পয়েন্ট সহ (তাই "নীড়")।
    • কোনও সংরক্ষণ পয়েন্ট পিছনে ঘোরানো লেনদেনের গণনা / স্তরের উপর প্রভাব ফেলেনি
    • প্রাথমিকের পূর্বে করা কোনও কাজ পুরো লেনদেনের SAVE TRANসম্পূর্ণ ইস্যু করা ব্যতীত পূর্বাবস্থায় ফেরানো যাবে না ROLLBACK
    • কেবল স্পষ্ট করে বলুন: COMMITযখন @@TRANCOUNT2 বা তার বেশি হয় তখন ইস্যু করা, সেভিং পয়েন্টগুলিতে কোনও প্রভাব ফেলবে না (কারণ আবার, 1 টির উপরে লেনদেনের স্তরগুলি এই কাউন্টারটির বাইরে বিদ্যমান নেই)।
  • আপনি নির্দিষ্ট নামের লেনদেন করতে পারবেন না commit "নাম" লেনদেনটি যদি এর সাথে সরবরাহ করা হয় তবে COMMITতা অগ্রাহ্য করা হয় এবং কেবল পঠনযোগ্যতার জন্য এটি বিদ্যমান।

  • একটি ROLLBACKএকটি নাম ছাড়া জারি সবসময় সমস্ত লেনদেন রোলব্যাক হবে।

  • একজন ROLLBACKপারেন একটি নাম আবশ্যক মিলা সঙ্গে ইস্যু করেছে:

    • প্রথম লেনদেন, এটির নাম
      ধরে SAVE TRANধরেই : فرض করে যে কোনও একই লেনদেনের নামে ডাকা হয়নি, এটি সমস্ত লেনদেনকে রোলব্যাক করবে।
    • একটি "সেভ পয়েন্ট" (উপরে বর্ণিত): সাম্প্রতিকতম বলা
      হওয়ার পরে এই আচরণটি সমস্ত পরিবর্তনকে "পূর্বাবস্থায়িত" করবে । SAVE TRAN {save_point_name}
    • প্রথম লেনদেনটি যদি ক) নামযুক্ত এবং খ) SAVE TRANএর নামের সাথে আদেশ জারি করা থাকে, তবে সেই লেনদেন নামের প্রত্যেকটি রোলব্যাকের প্রতিটি সেভ পয়েন্ট পূর্বেই পূর্বাবস্থায় ফেলা হবে যতক্ষণ না এই নামটির কোনও বাকী থাকে না। এর পরে, সেই নামটি জারি করা একটি রোলব্যাক সমস্ত লেনদেনকে রোলব্যাক করবে।
    • উদাহরণস্বরূপ, ধরে নিন যে নিম্নলিখিত আদেশগুলি দেখানো ক্রমে চালিত হয়েছিল:

      BEGIN TRAN A -- @@TRANCOUNT is now 1
      -- DML Query 1
      SAVE TRAN A
      -- DML Query 2
      SAVE TRAN A
      -- DML Query 3
      
      BEGIN TRAN B -- @@TRANCOUNT is now 2
      SAVE TRAN B
      -- DML Query 4

      এখন, যদি আপনি ইস্যু করেন (নীচের প্রতিটি পরিস্থিতি একে অপরের থেকে পৃথক):

      • ROLLBACK TRAN Bএকবার: এটি "ডিএমএল ক্যোয়ারী 4" পূর্বাবস্থায় ফিরে আসবে। @@TRANCOUNTএখনও 2।
      • ROLLBACK TRAN Bদু'বার: এটি "ডিএমএল ক্যোয়ারী 4" কে পূর্বাবস্থায় ফিরিয়ে আনবে এবং তত্ক্ষণাত "বি" এর সাথে সম্পর্কিত কোনও সংরক্ষণ পয়েন্ট না থাকায় ত্রুটি হবে। @@TRANCOUNTএখনও 2।
      • ROLLBACK TRAN Aএকবার: এটি "ডিএমএল ক্যোয়ারী 4" এবং "ডিএমএল ক্যোয়ারী 3" পূর্বাবস্থায় ফিরে আসবে। @@TRANCOUNTএখনও 2।
      • ROLLBACK TRAN Aদুবার: এটি "ডিএমএল ক্যোয়ারী 4", "ডিএমএল ক্যোয়ারী 3" এবং "ডিএমএল ক্যোয়ারী 2" পূর্বাবস্থায় ফিরে আসবে। @@TRANCOUNTএখনও 2।
      • ROLLBACK TRAN Aতিনবার: এটি "ডিএমএল ক্যোয়ারী 4", "ডিএমএল ক্যোয়ারী 3" এবং "ডিএমএল ক্যোয়ারী 2" পূর্বাবস্থায় ফিরে আসবে। তারপরে এটি পুরো লেনদেনের রোলব্যাক করবে (যা যা ছিল তা ছিল "ডিএমএল ক্যোয়ারী 1")। @@TRANCOUNTএখন 0।
      • COMMITএকবার: @@TRANCOUNT1 এ নেমে যায়।
      • COMMITএকবার এবং তারপরে ROLLBACK TRAN Bএকবার: @@TRANCOUNTনীচে নেমে যায় 1 এরপরে এটি "ডিএমএল ক্যোয়ারী 4" পূর্বাবস্থায় ফিরবে (প্রমাণ করে যে কমিট কিছুই করেনি)। @@TRANCOUNTএখনও 1।
  • লেনদেনের নাম এবং সেভ পয়েন্টের নাম:

  • একটি সঞ্চিত পদ্ধতি নিজেই, একটি অন্তর্নিহিত লেনদেন নয়। যদি কোনও স্পষ্ট লেনদেন শুরু না করা হয় তবে প্রতিটি কোয়েরি হ'ল একটি অন্তর্নিহিত লেনদেন। একারণে কোনও প্রোগ্রামিক কারণ না থাকলে সিঙ্গলিক ক্যোয়ারির চারপাশে সুস্পষ্ট লেনদেনের প্রয়োজন হয় না ROLLBACK, অন্যথায় ক্যোয়ারিতে কোনও ত্রুটি হল সেই ক্যোয়ারীর একটি স্বয়ংক্রিয় রোলব্যাক।

  • কোনও সঞ্চিত প্রক্রিয়া কল করার সময়, এটি @@TRANCOUNTযখন বলা হয়েছিল ঠিক একই মান সহ প্রস্থান করতে হবে । অর্থ, আপনি পারবেন না:

    • BEGIN TRANকলিং / প্যারেন্ট প্রসেসে প্রতিশ্রুতি রাখার প্রত্যাশা না করেই এটি প্রতিশ্রুতিবদ্ধ না করেই প্র্যাকটিতে একটি শুরু করুন ।
    • ROLLBACKপ্রোক বলা হওয়ার আগে যদি একটি সুস্পষ্ট লেনদেন শুরু হয় তবে এটি @@TRANCOUNT0 এ ফিরে আসবে আপনি এটি ইস্যু করতে পারবেন না ।

    যদি আপনি কোনও লেনদেনের গণনা সহ কোনও সঞ্চিত প্রক্রিয়াটি প্রস্থান করেন যা এটি তাকানর চেয়ে বেশি বা কম হয় তবে আপনি এর মতো একটি ত্রুটি পাবেন:

    এমএসজি 266, স্তর 16, রাজ্য 2, পদ্ধতি আপনার প্রসনাম, লাইন 0
    লেনদেনের গণনা EXECUTE এর পরে বিগইন এবং কমিট স্টেটমেন্টের মিল নেই। পূর্ববর্তী গণনা = এক্স, বর্তমান গণনা = ওয়াই

  • সারণী ভেরিয়েবলগুলি, যেমন নিয়মিত ভেরিয়েবলগুলির মতো, লেনদেন দ্বারা আবদ্ধ হয় না।


প্রক্সগুলিতে লেনদেন পরিচালনার বিষয়ে যা স্বাধীনভাবে বলা যেতে পারে (এবং এজন্য লেনদেন পরিচালনার প্রয়োজন হয়) বা অন্যান্য প্রকস থেকে কল আসে (সুতরাং লেনদেন পরিচালনার প্রয়োজন হয় না): এটি বেশ কয়েকটি উপায়ে সম্পন্ন করা যায়।

আমি বেশ কয়েক বছর ধরে যেভাবে এটি পরিচালনা করছি যেটি এখন বেশ ভালভাবে কাজ করছে বলে মনে হচ্ছে কেবলমাত্র BEGIN/ COMMIT/ ROLLBACKবহিরাগত স্তরের দিকে। সাব-প্রোক কলগুলি কেবলমাত্র লেনদেনের আদেশগুলি বাদ দেয়। আমি প্রত্যেকটি প্রকল্পে যা রেখেছি তার নীচে রূপরেখা জানিয়েছি (ভাল, প্রতিটি যেটির জন্য লেনদেন পরিচালনার প্রয়োজন হয়)।

  • প্রতিটি প্রকোষ্ঠের শীর্ষে, DECLARE @InNestedTransaction BIT;
  • সরল জায়গায় BEGIN TRAN, করুন:

    IF (@@TRANCOUNT = 0)
    BEGIN
       SET @InNestedTransaction = 0;
       BEGIN TRAN; -- only start a transaction if not already in one
    END;
    ELSE
    BEGIN
       SET @InNestedTransaction = 1;
    END;
  • সরল জায়গায় COMMIT, করুন:

    IF (@@TRANCOUNT > 0 AND @InNestedTransaction = 0)
    BEGIN
       COMMIT;
    END;
  • সরল জায়গায় ROLLBACK, করুন:

    IF (@@TRANCOUNT > 0 AND @InNestedTransaction = 0)
    BEGIN
       ROLLBACK;
    END;

এসকিউএল সার্ভারের মধ্যে লেনদেন শুরু হয়েছিল কিনা বা অ্যাপ স্তরটিতে এটি শুরু হয়েছিল কিনা তা বিবেচনা না করেই এই পদ্ধতির একই কাজ করা উচিত।

TRY...CATCHকনস্ট্রাক্টের মধ্যে এই লেনদেনের হ্যান্ডলিংয়ের সম্পূর্ণ টেমপ্লেটের জন্য , দয়া করে নীচের ডিবিএ.এসই প্রশ্নের আমার উত্তরটি দেখুন: আমাদের কি সি # কোড এবং সেই সাথে সঞ্চিত পদ্ধতিতে লেনদেন পরিচালনা করতে হবে ?


"বুনিয়াদি" এর বাইরে চলে যাওয়া, সম্পর্কে অবহিত হওয়ার জন্য লেনদেনের কিছু অতিরিক্ত সূক্ষ্মতা রয়েছে:

  • ডিফল্টরূপে, লেনদেনগুলি বেশিরভাগ সময় হয়, যখন কোনও ত্রুটি ঘটে তখন স্বয়ংক্রিয়ভাবে ঘূর্ণিত-ব্যাক / বাতিল হয় না। আপনার যথাযথ ত্রুটি পরিচালনা করা এবং ROLLBACKনিজেকে কল করা পর্যন্ত এটি সাধারণত কোনও সমস্যা হয় না । যাইহোক, কখনও কখনও জিনিসগুলি জটিল হয়ে যায়, যেমন ব্যাচ-গর্ভপাত ত্রুটির ক্ষেত্রে বা OPENQUERY(বা সাধারণভাবে সংযুক্ত সার্ভারগুলি) ব্যবহার করার সময় এবং রিমোট সিস্টেমে একটি ত্রুটি দেখা দেয়। বেশিরভাগ ত্রুটিগুলি ব্যবহার করে আটকা TRY...CATCHপড়তে পারে, তবে দুটি আছে যা সেভাবে আটকা যায় না (এই মুহূর্তে কোনটি মনে করতে পারে না, যদিও - গবেষণা করছে)। এই ক্ষেত্রে, আপনার অবশ্যই SET XACT_ABORT ONলেনদেনের রোলব্যাক সঠিকভাবে ব্যবহার করতে হবে ।

    এসইটি XACT_ABORT অন এসকিউএল সার্ভারকে তত্ক্ষণাত যে কোনও লেনদেনের রোল-ব্যাক করতে দেয় (যদি কেউ সক্রিয় থাকে) এবং কোনও ত্রুটি দেখা দিলে ব্যাচটি বাতিল করতে হবে । এই সেটিংটি এসকিউএল সার্ভার ২০০৫ এর আগে বিদ্যমান ছিল, যা TRY...CATCHনির্মাণের সূচনা করেছিল । বেশিরভাগ ক্ষেত্রে, TRY...CATCHবেশিরভাগ পরিস্থিতি পরিচালনা করে এবং তাই বেশিরভাগ ক্ষেত্রে প্রয়োজনটি অপ্রচলিত করে XACT_ABORT ON। যাইহোক, ব্যবহার করার সময় OPENQUERY(এবং সম্ভবত অন্য একটি দৃশ্য যা আমি এই মুহুর্তে মনে করতে পারি না), তারপরে আপনাকে এখনও ব্যবহার করতে হবে SET XACT_ABORT ON;

  • ভিতরে একটি ট্রিগার, XACT_ABORTঅন্তর্নিহিত সেট করা আছে ON। এটি ট্রিগারটির বাইরে থাকা পুরো ডিএমএল বিবৃতি বাতিল করতে ট্রিগারটির মধ্যে কোনও ত্রুটি সৃষ্টি করে।

  • আপনার সর্বদা সঠিক ত্রুটি পরিচালনা করা উচিত, বিশেষত যখন লেনদেনগুলি ব্যবহার করার সময়। TRY...CATCHকনস্ট্রাক্ট, এসকিউএল সার্ভার 2005 সালে চালু, প্রায় সব পরিস্থিতিতে জন্য পরীক্ষা উপর একটি স্বাগত উন্নতি হ্যান্ডলিং একটি উপায় প্রদান করে @@ERRORপ্রতিটি বিবৃতি, যা ব্যাচ-গর্ভপাত ত্রুটিযুক্ত অনেক সাহায্য করা হয়নি পরে।

    TRY...CATCHতবে একটি নতুন "রাষ্ট্র" চালু করেছে। যখন না ব্যবহার TRY...CATCHকনস্ট্রাক্ট, যদি আপনি একটি সক্রিয় লেনদেন আছে এবং একটি ত্রুটি ঘটে, তারপর সেখানে বিভিন্ন পাথ যে গ্রহণ করা যেতে পারে আছে:

    • XACT_ABORT OFFএবং বিবৃতি-বিলোপ ত্রুটি: লেনদেন এখনও সক্রিয় এবং পরবর্তী বিবৃতি , যদি থাকে তবে প্রক্রিয়া চলতে থাকে।
    • XACT_ABORT OFFএবং সর্বাধিক ব্যাচ-গর্ভপাত ত্রুটি: লেনদেন এখনও সক্রিয় রয়েছে এবং পরবর্তী ব্যাচে যদি প্রক্রিয়া থাকে তবে প্রক্রিয়াজাতকরণ অব্যাহত থাকে।
    • XACT_ABORT OFFএবং নির্দিষ্ট ব্যাচ-গর্ভপাত ত্রুটি: লেনদেনটি ঘূর্ণিত হয় এবং যদি থাকে তবে পরবর্তী ব্যাচে প্রক্রিয়াজাতকরণ অব্যাহত থাকে।
    • XACT_ABORT ONএবং যে কোনও ত্রুটি: লেনদেনটি রোলড-ব্যাক হয় এবং প্রক্রিয়াটি যদি থাকে তবে পরবর্তী ব্যাচটি দিয়ে চলতে থাকে if


    তবুও, ব্যবহার করার সময় TRY...CATCH, ব্যাচ-গর্ভাবস্থার ত্রুটিগুলি ব্যাচটি বাতিল না করে পরিবর্তে CATCHব্লকটিতে নিয়ন্ত্রণ স্থানান্তর করে । কখন XACT_ABORTহয় OFF, লেনদেন এখনও সময়ের বেশিরভাগ অংশে সক্রিয় থাকবে এবং আপনাকে COMMIT, বা সম্ভবত সম্ভবত, প্রয়োজন হবে ROLLBACK। তবে যখন নির্দিষ্ট ব্যাচ-গর্ভপাত ত্রুটির মুখোমুখি হওয়া (যেমন সহ OPENQUERY) বা যখন XACT_ABORTহয় ONতখন লেনদেনটি একটি নতুন অবস্থায় থাকবে, "আপত্তিজনক"। এই অবস্থায় আপনি পারবেন না COMMIT, আপনি কোনও ডিএমএল অপারেশনও করতে পারবেন না । আপনি যা করতে পারেন তা হ'ল ROLLBACKএবং SELECTবিবৃতি। যাইহোক, এই "আপত্তিজনক" অবস্থায়, ত্রুটিটি ঘটতে থাকলে লেনদেনটি ঘুরিয়ে দেওয়া হয়েছিল, এবং জারি ROLLBACKকরা কেবল একটি আনুষ্ঠানিকতা, তবে একটি অবশ্যই করা উচিত।

    কোনও ক্রিয়াকলাপ, XACT_STATE , কোনও লেনদেন সক্রিয়, আপত্তিজনক বা উপস্থিত না থাকলে তা নির্ধারণ করতে ব্যবহার করা যেতে পারে। ফলাফল পরীক্ষা CATCHকরার -1পরিবর্তে ফলাফল (অর্থাত্‍ অবিস্মরণীয় ) আছে কিনা তা নির্ধারণ করার জন্য ব্লকের এই ফাংশনটি পরীক্ষা করার জন্য (কিছু দ্বারা কমপক্ষে) সুপারিশ করা হয় @@TRANCOUNT > 0। কিন্তু XACT_ABORT ONযে হওয়া উচিত শুধুমাত্র সম্ভব রাষ্ট্র, হতে তাই এটি যে পরীক্ষামূলক বলে মনে হয় @@TRANCOUNT > 0এবং XACT_STATE() <> 0সমতুল্য। অন্যদিকে, যখন XACT_ABORTহয় OFFএবং সেখানে একটি সক্রিয় লেনদেন হয়, তাহলে এটা সম্ভব হয় একটি রাষ্ট্র আছে হয় 1বা -1CATCHব্লক, যা জারি করে প্রতারণা করতে পারবে COMMITপরিবর্তে ROLLBACKযখন কারোর জন্য (যদিও, আমি একটি মামলার ভাবতে পারি না চাইবেCOMMITযদি লেনদেনটি কমিটমেন্টযোগ্য হয়)। XACT_STATE()একটি CATCHব্লকের মধ্যে ব্যবহারের বিষয়ে আরও তথ্য এবং গবেষণা XACT_ABORT ONনিম্নলিখিত ডিবিএ.এসই প্রশ্নের উত্তরে পাওয়া যাবে: XACT_ABORT চালু হওয়ার পরে কোন ক্ষেত্রে ক্যাচ ব্লকের অভ্যন্তর থেকে কোনও লেনদেন করা যেতে পারে? । দয়া করে মনে রাখবেন যে এখানে একটি ছোট্ট ত্রুটি রয়েছে XACT_STATE()যার ফলে এটি 1কিছু পরিস্থিতিতে ভুলভাবে ফিরে আসে : কিছু সিস্টেম ভেরিয়েবলের সাথে SEF এ ব্যবহৃত হয় তবে FROM ধারা ছাড়াই XACT_STATE () 1 প্রদান করে


মূল কোড সম্পর্কে নোট:

  • লেনদেনের দেওয়া নামটি আপনি মুছে ফেলতে পারেন কারণ এটি কোনওরকম সহায়তা করে না।
  • আপনার প্রতিটি কল BEGINএবং তার ENDচারপাশের দরকার নেইEXEC

2
এটি সত্যিই ভাল, ভাল, উত্তর।
ম্যাকনেট

1
বাহ, এটি একটি ব্যাপক উত্তর! ধন্যবাদ! নিম্নলিখিত পৃষ্ঠায় বিটিডাব্লু ডস আপনি যে ত্রুটিগুলি বোঝাচ্ছেন সেটিকে সম্বোধন করে চেষ্টা করুন ... ক্যাচ দিয়ে আটকাবেন না? (শিরোনামের "একটি চেষ্টা করুন ... ধরা কনস্ট্রাক্ট দ্বারা প্রভাবিত ত্রুটিগুলি" অধীনে? Technet.microsoft.com/en-us/library/ms175976(v=sql.110).aspx
jrdevdba

1
@jrdevdba ধন্যবাদ :-)। এবং ইয়ার স্বাগতম। ত্রুটিগুলি আটকা হয়নি সম্পর্কে, আমি প্রায় এই দুটি বোঝাতে চেয়েছিলাম: Compile errors, such as syntax errors, that prevent a batch from runningএবং Errors that occur during statement-level recompilation, such as object name resolution errors that occur after compilation because of deferred name resolution.। তবে এগুলি খুব ঘন ঘন ঘটে না এবং আপনি যখন এ জাতীয় পরিস্থিতি খুঁজে পান, হয় তা ঠিক করুন (যদি কোডটিতে এটি কোনও বাগ থাকে) অথবা এটি একটি উপ-প্রক্রিয়াতে ( EXECবা sp_executesql) রাখুন যাতে এটি TRY...CATCHআটকে যায়।
সলোমন রুটজকি

2

হ্যাঁ, যদি আপনার মাস্টার সঞ্চিত প্রক্রিয়াটির ক্যাচ স্টেটমেন্টে কোনও ত্রুটি রোলব্যাক কোডের কারণে কার্যকর হয় তবে এটি কোনও সরাসরি বিবৃতি দ্বারা বা এটিতে আপনার নেস্টেড স্টোরেজ পদ্ধতির কোনও মাধ্যমে সমস্ত ক্রিয়াকলাপ রোলব্যাক করবে will

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

প্রতিবার লেনদেন হয় প্রতিশ্রুতিবদ্ধ হয় বা বহিরাগততম লেনদেন শেষে যে ব্যবস্থা নেওয়া হয় তার ভিত্তিতে ফিরে আসে। যদি বাইরের লেনদেন প্রতিশ্রুতিবদ্ধ হয় তবে অভ্যন্তরীণ নেস্টেড লেনদেনগুলিও প্রতিশ্রুতিবদ্ধ। যদি বাইরের লেনদেনটি আবার ঘূর্ণিত হয়, তবে অভ্যন্তরীণ লেনদেন স্বতন্ত্রভাবে প্রতিশ্রুতিবদ্ধ ছিল কিনা তা বিবেচনা না করেই সমস্ত অভ্যন্তরীণ লেনদেনগুলিও আবার ঘুরিয়ে দেওয়া হয়।

রেফারেন্সের জন্য http://technet.microsoft.com/en-us/library/ms189336(v=sql.105).aspx

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.