مقدمه

@@ERROR یکی از قابلیت‌های سیستمی Transact-SQL است که در عیب‌یابی، کنترل عملیات و ثبت Metadata کاربرد دارد. این مقاله از تعریف پایه شروع می‌کند و سپس با ده مثال مستقل، رفتار واقعی آن را در SQL Server توضیح می‌دهد.

شماره خطای آخرین دستور Transact-SQL را در همان اتصال گزارش می‌کند و در صورت نبود خطا مقدار صفر می‌دهد. دانستن همین تعریف کافی نیست؛ باید مرز نشست، Scope، آخرین Statement و اثر دستورهای بعدی را نیز شناخت تا مقدار خروجی به اشتباه به عملیات دیگری نسبت داده نشود.

در پروژه‌های عملی بهتر است استفاده از @@ERROR بخشی از یک قرارداد روشن باشد: دستور اجرا می‌شود، مقدار بلافاصله دریافت می‌گردد، وضعیت خطا یا تراکنش کنترل می‌شود و نتیجه لازم برای لاگ یا لایه برنامه بازگردانده می‌شود.

برای مشاهده جایگاه این قابلیت در کنار سایر توابع سیستمی، راهنمای جامع توابع سیستمی SQL Server را نیز مطالعه کنید.

تعریف، کاربرد و مرز عملکرد

نوع خروجی @@ERROR برابر int است. هنگام ذخیره در ستون یا متغیر، نوع مقصد را آگاهانه انتخاب کنید؛ تبدیل ضمنی ممکن است در حجم بالا، مقدار بزرگ یا تغییر Schema باعث خطای سرریز یا رفتار پیش‌بینی‌نشده شود.

مقدار فقط برای دستور بلافاصله قبل معتبر است و برای کدهای جدید، TRY...CATCH و ERROR_NUMBER معمولاً انتخاب خواناتر و مطمئن‌تری هستند. این نکته به‌ویژه زمانی مهم است که Trigger، Dynamic SQL، Stored Procedure تو‌در‌تو، Connection Pooling یا چند دستور تشخیصی در مسیر اجرا وجود دارد.

خروجی صفر، NULL یا مقدار قدیمی الزاماً خطای موتور نیست؛ گاهی تعریف تابع دقیقاً چنین رفتاری دارد. برای تحلیل درست، یک آزمایش کوچک در همان اتصال بسازید و قبل و بعد از هر Statement مقدارهای مرتبط را ثبت کنید.

قاعده طلایی: مقدار فقط برای دستور بلافاصله قبل معتبر است و برای کدهای جدید، TRY...CATCH و ERROR_NUMBER معمولاً انتخاب خواناتر و مطمئن‌تری هستند. نتیجه را همراه با زمینه اجرا تفسیر کنید و از تبدیل یک مقدار سیستمی به فرض تجاری بدون آزمون پرهیز نمایید.

Syntax و نوع خروجی

نحو پایه @@ERROR کوتاه است، اما محل فراخوانی آن معنای خروجی را تعیین می‌کند. نمونه زیر خروجی را با نام ستونی واضح ارائه می‌دهد تا مصرف آن در ابزار گزارش‌گیری یا کد برنامه خوانا باشد.

SELECT @@ERROR AS LastErrorNumber;

نوع بازگشتی int است. برای API یا لایه داده، نوع C# یا مقصد پایگاه داده را مطابق همین نوع و دامنه مقادیر انتخاب کنید و حالت NULL را، هرجا از نظر معنایی ممکن است، صریح مدیریت نمایید.

مثال‌های عملی از پایه تا حرفه‌ای

ده مثال زیر مستقل طراحی شده‌اند. هر نمونه هدف، Query کامل، خروجی مورد انتظار و نکته کاربردی دارد. اشیای آزمایشی را در پایگاه توسعه اجرا کنید و از اجرای کدهای آموزشی روی Production بدون بازبینی مجوز و اثر قفل خودداری نمایید.

SELECT 1 AS Value;
    SELECT @@ERROR AS ErrorNumber;

SELECT TOP (1) name FROM sys.objects;
    DECLARE @Err int = @@ERROR;
    SELECT @Err AS CapturedError;

UPDATE sys.tables SET lock_on_bulk_load = lock_on_bulk_load WHERE 1 = 0;
    DECLARE @Err int = @@ERROR, @Rows int = @@ROWCOUNT;
    SELECT @Err AS ErrorNumber, @Rows AS AffectedRows;

SELECT 100 / 5 AS Result;
    IF @@ERROR = 0
        SELECT N'عملیات موفق بود' AS Message;

BEGIN TRY
        SELECT 10 / 0 AS Result;
    END TRY
    BEGIN CATCH
        SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() AS ErrorMessage;
    END CATCH;

BEGIN TRY
        SELECT CONVERT(int, N'ABC') AS Value;
    END TRY
    BEGIN CATCH
        SELECT ERROR_NUMBER() AS ErrorNumber;
    END CATCH;

CREATE TABLE #U(Id int PRIMARY KEY);
    INSERT #U VALUES (1);
    BEGIN TRY
        INSERT #U VALUES (1);
    END TRY
    BEGIN CATCH
        SELECT ERROR_NUMBER() AS ErrorNumber;
    END CATCH;
    DROP TABLE #U;

DECLARE @Log TABLE(ErrorNumber int, ErrorMessage nvarchar(4000));
    BEGIN TRY
        THROW 51000, N'خطای آزمایشی', 1;
    END TRY
    BEGIN CATCH
        INSERT @Log VALUES(ERROR_NUMBER(), ERROR_MESSAGE());
    END CATCH;
    SELECT * FROM @Log;

SELECT 1 AS FirstStatement;
    SELECT 2 AS InterveningStatement;
    SELECT @@ERROR AS LateRead;
    SELECT 1 AS NewStatement;
    DECLARE @Immediate int = @@ERROR;
    SELECT @Immediate AS CorrectRead;

BEGIN TRY
        BEGIN TRANSACTION;
        SELECT 10 / 2 AS SafeResult;
        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
        SELECT ERROR_NUMBER() AS ErrorNumber;
    END CATCH;

خطاهای رایج

بخش مهم یادگیری @@ERROR شناخت خطاهایی است که Syntax صحیح دارند اما منطق نادرست تولید می‌کنند. این خطاها ممکن است در تست تک‌کاربره دیده نشوند و فقط زیر بار یا با Trigger آشکار گردند.

• 1. خواندن @@ERROR پس از اجرای یک دستور واسط. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 2. انتظار دریافت متن خطا به‌جای شماره. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 3. ادامه تراکنش بدون بررسی XACT_STATE. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 4. ترکیب کنترل قدیمی @@ERROR با CATCH بدون قرارداد روشن. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.

در رخداد واقعی، تنها پیام خطا کافی نیست. نام Procedure، شماره خط، ورودی‌های پالایش‌شده، وضعیت تراکنش و شناسه نشست را ثبت کنید تا علت اصلی از نشانه ثانویه تفکیک شود.

Performance و بهینه‌سازی

هزینه محاسباتی ناچیزی دارد، اما کنترل خطای ردیف‌به‌ردیف می‌تواند جریان برنامه را پیچیده و عملیات را کند کند.

برای سنجش اثر واقعی، قبل و بعد از تغییر کد از Query Store، Actual Execution Plan، SET STATISTICS IO/TIME و در صورت نیاز Extended Events استفاده کنید. اندازه‌گیری باید روی Query اصلی، تعداد Logical Read، زمان CPU، مدت قفل و حجم Log متمرکز باشد.

از اجرای Query اضافی فقط برای بازسازی اطلاعاتی که موتور همان لحظه در اختیار گذاشته اجتناب کنید. در عین حال، تابع سیستمی را جایگزین کنترل صحت داده، Constraint، ایندکس مناسب یا طراحی Transaction نکنید.

در پردازش گروهی، نتیجه هر Batch را ثبت کنید و اندازه Batch را طوری تنظیم نمایید که زمان قفل و رشد Log قابل کنترل باشد. شکست جزئی باید سیاست Retry محدود و Idempotency مشخص داشته باشد.

بهترین روش‌ها و کاربرد سازمانی

• مقدار @@ERROR را در نزدیک‌ترین نقطه به دستور مرجع بخوانید.
• نوع خروجی int و امکان NULL یا صفر را صریح در مدل داده لحاظ کنید.
• برای خطا از TRY...CATCH، THROW و XACT_STATE با قرارداد یکسان استفاده کنید.
• کد را زیر هم‌زمانی واقعی و در حضور Trigger یا Connection Pooling آزمایش کنید.
• از Hard-code کردن نام محیط و فرض‌های وابسته به ترتیب اجرا خودداری کنید.
• در لاگ، SPID، زمان، نام دیتابیس و شناسه همبستگی را بدون داده حساس نگه دارید.

در سامانه‌های فروش، مالی، انبار، اتوماسیون یا گزارش‌گیری، این الگو به تیم پشتیبانی کمک می‌کند نتیجه هر عملیات را سریع‌تر ردیابی کند. ارزش اصلی زمانی ایجاد می‌شود که Metadata فنی با شناسه تجاری سفارش یا درخواست مرتبط شود.

برای مهاجرت نسخه یا انتقال به محیط جدید، مجموعه تست سازگاری بسازید. Compatibility Level، مجوز DMVها، رفتار Driver و تنظیمات Connection Pool می‌توانند روی مشاهده‌پذیری پیرامون تابع اثر بگذارند، حتی اگر Syntax خود تابع ثابت مانده باشد.

سؤالات متداول

پرسش 1: @@ERROR دقیقاً چه کاری انجام می‌دهد؟

@@ERROR شماره خطای آخرین دستور Transact-SQL را در همان اتصال گزارش می‌کند و در صورت نبود خطا مقدار صفر می‌دهد. خروجی باید در متن همان Batch و با توجه به Scope، Session و دستور قبلی تفسیر شود؛ جدا کردن آن از زمینه اجرا می‌تواند نتیجه‌ای ظاهراً درست اما از نظر تجاری اشتباه بسازد.

پرسش 2: بهترین زمان خواندن @@ERROR چه موقع است؟

بهترین زمان بلافاصله پس از دستور مرتبط است. اگر مقدار برای چند مرحله بعد لازم است، آن را در متغیری با نوع مناسب ذخیره کنید و همراه شناسه عملیات ثبت نمایید تا دستورهای واسط مقدار یا معنای آن را تغییر ندهند.

پرسش 3: آیا @@ERROR برای سامانه‌های سازمانی مناسب است؟

بله، مشروط بر اینکه قرارداد استفاده، مدیریت خطا و تست هم‌زمانی مشخص باشد. در طراحی حرفه‌ای، این تابع بخشی از راه‌حل است و در کنار Transaction، Logging، مجوز حداقلی و پایش Query به کار می‌رود.

پرسش 4: برای پیاده‌سازی صحیح آن به مشاوره SQL Server نیاز است؟

در کد ساده خیر، اما در سامانه‌های مالی، انبار، احراز هویت یا پردازش گروهی بررسی Triggerها، Scopeها و الگوی تراکنش اهمیت زیادی دارد. بازبینی تخصصی می‌تواند از خطاهای خاموش و هزینه اصلاح داده جلوگیری کند.

پرسش 5: تفاوت @@ERROR با گزینه‌های نزدیک چیست؟

تفاوت اصلی در دامنه مشاهده و نوع اطلاعات است. باید مشخص شود نیاز شما مربوط به آخرین Statement، نشست جاری، Scope جاری، جدول مشخص یا Metadata سرور است؛ سپس تابعی انتخاب شود که دقیقاً همان مرز را پوشش دهد.

پرسش 6: آیا می‌توان این الگو را در Stored Procedure پروژه پیاده کرد؟

بله. بهتر است مقدار در همان Procedure گرفته شود، نوع خروجی صریح باشد، خطا با TRY...CATCH مدیریت شود و نتیجه از طریق Result Set، پارامتر OUTPUT یا قرارداد سرویس بازگردد. تست یکپارچه نیز حالت موفق و شکست را پوشش دهد.

پرسش 7: خطای رایج هنگام استفاده از @@ERROR چیست؟

خواندن @@ERROR پس از اجرای یک دستور واسط یکی از خطاهای متداول است. خطای دیگر، اتکا به نتیجه بدون ثبت Context اجراست. نسخه اصلاح‌شده باید زمان خواندن، Scope، رفتار تراکنش و نوع تبدیل را آشکار کند.

پرسش 8: اثر @@ERROR بر Performance چیست؟

هزینه محاسباتی ناچیزی دارد، اما کنترل خطای ردیف‌به‌ردیف می‌تواند جریان برنامه را پیچیده و عملیات را کند کند. هزینه اصلی معمولاً از Query یا Transaction پیرامون آن می‌آید، نه خود تابع. اندازه‌گیری با Actual Execution Plan، Query Store و Extended Events باید روی کل جریان انجام شود.

پرسش 9: Best Practice اصلی برای @@ERROR چیست؟

مقدار را نزدیک به دستور مرجع بخوانید، در نوع مناسب ذخیره کنید، نتیجه‌های مرزی مانند صفر یا NULL را تست کنید و برای عملیات حساس گزارش ممیزی بسازید. از تکیه بر ترتیب اتفاقی دستورات یا رشته‌های Hard-coded دوری کنید.

پرسش 10: این قابلیت در کدام نسخه‌های SQL Server کار می‌کند؟

این قابلیت در نسخه‌های رایج و پشتیبانی‌شده SQL Server در دسترس است، اما امکانات مکمل مانند SESSION_CONTEXT، THROW یا برخی DMVها به نسخه و سطح سازگاری وابسته‌اند. پیش از استقرار، مستندات همان نسخه و Compatibility Level پایگاه داده را کنترل کنید.

سؤالات مصاحبه SQL Server

سؤال 1: مرز مشاهده @@ERROR چیست؟

پاسخ حرفه‌ای باید مشخص کند تابع به Statement، Scope، Session، Table یا Server مربوط است و یک مثال نقض نیز ارائه دهد. گفتن نام تابع بدون توضیح مرز مشاهده برای مصاحبه فنی کافی نیست.

سؤال 2: چگونه مقدار را بدون Race Condition مصرف می‌کنید؟

مقدار باید نزدیک به عملیات مرجع، در همان اتصال و داخل قرارداد تراکنش خوانده شود. برای چند ردیف یا خروجی‌های حساس، قابلیت OUTPUT یا Metadata ساخت‌یافته می‌تواند انتخاب دقیق‌تری باشد.

سؤال 3: در CATCH چه اطلاعاتی ثبت می‌کنید؟

شماره و متن خطا، Procedure، Line، XACT_STATE، @@TRANCOUNT، نام پایگاه داده، SPID و شناسه همبستگی از اطلاعات مفید هستند. داده حساس نباید بدون پالایش وارد Log شود.

سؤال 4: چطور این کد را تست می‌کنید؟

تست موفق، نتیجه خالی، خطا، تراکنش باز، اجرای هم‌زمان و وجود Trigger یا دستور واسط باید جداگانه پوشش داده شود. تست باید مقدار خروجی و وضعیت نهایی داده را هر دو بررسی کند.

سؤال 5: چه زمانی گزینه دیگری را انتخاب می‌کنید؟

وقتی تابع مرز موردنیاز را پوشش نمی‌دهد یا فقط یک مقدار از مجموعه‌ای بزرگ را برمی‌گرداند. انتخاب باید بر اساس هدف تجاری، هم‌زمانی، نسخه SQL Server و قابلیت مشاهده‌پذیری انجام شود.

چک‌لیست نهایی

• تعریف و مرز @@ERROR را با یک مثال توضیح داده‌ام.
• مقدار بلافاصله پس از دستور مرتبط ذخیره می‌شود.
• حالت صفر، NULL، خطا و هم‌زمانی تست شده است.
• تراکنش در مسیر موفق Commit و در مسیر شکست Rollback می‌شود.
• نتیجه با نوع مناسب و نام ستون روشن به لایه مصرف‌کننده می‌رسد.
• لاگ فنی برای عیب‌یابی وجود دارد و داده حساس ثبت نمی‌شود.

جمع‌بندی

@@ERROR شماره خطای آخرین دستور Transact-SQL را در همان اتصال گزارش می‌کند و در صورت نبود خطا مقدار صفر می‌دهد. استفاده حرفه‌ای از آن به معنی شناخت دقیق مرز، خواندن در زمان مناسب، مدیریت نوع خروجی و آزمون رفتار در شرایط واقعی است.

برای تکمیل مسیر یادگیری و مقایسه با قابلیت‌های مرتبط، به مقاله مادر توابع سیستمی SQL Server بازگردید. مثال‌ها را ابتدا در محیط آزمایشی اجرا و سپس با استاندارد تراکنش، امنیت و مانیتورینگ پروژه خود تطبیق دهید.