خطای MySQL 1146؛ جدول وجود ندارد یا برنامه به دیتابیس اشتباه وصل شده است؟

سایت یا برنامه خطایی شبیه Table 'database.table' doesn't exist و کد 1146 نشان می‌دهد. یعنی MySQL هنگام اجرای درخواست نتوانسته جدول موردنظر را با آن نام در آن پایگاه داده پیدا کند. علت می‌تواند انتخاب دیتابیس اشتباه، نام یا پیشوند متفاوت، انتقال ناقص یا واقعاً نبودن جدول باشد.

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

در پیام نمونه زیر، shopdb نام پایگاه داده و wp_orders نام جدول فرضی است:

این نام‌ها را با خطای واقعی خود جایگزین کنید. محل خطا و زمان آن را یادداشت کنید: آیا کل سایت از کار افتاده یا فقط یک افزونه، گزارش یا عملیات ورود؟ اگر خطا فقط در گزارش خصوصی سرور ثبت می‌شود، جزئیات آن را عمومی نکنید. مرجع خطای MySQL کد ۱۱۴۶ را برای پیدا نشدن جدول معرفی می‌کند.

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

در cPanel یا کنترل‌پنل خود وارد phpMyAdmin شوید. از ستون کناری، نام پایگاه داده‌ای را که در خطا آمده انتخاب کنید. اگر چند دیتابیس با نام شبیه دارید، پیشوند حساب هاست و نام کامل را دقیق بخوانید. در محیط SQL همان پایگاه داده می‌توانید فرمان فقط‌خواندنی زیر را اجرا کنید:

خروجی نام پایگاه داده انتخاب‌شده را نشان می‌دهد؛ اگر NULL است، در آن نشست پایگاه داده پیش‌فرض انتخاب نشده است. سپس فهرست جدول‌های قابل مشاهده برای همان حساب را ببینید:

این دستور داده‌ای را تغییر نمی‌دهد. نام جدول خطا را با فهرست، حرف‌به‌حرف مقایسه کنید. اگر حساب دسترسی کافی ندارد، از مدیر پایگاه داده بخواهید وجود جدول و مجوز همین کاربر را بررسی کند. مستند MySQL برای SHOW TABLES یادآوری می‌کند جدول بدون مجوز ممکن است در فهرست نمایش داده نشود.

در وردپرس، فایل پیکربندی سایت معمولاً نام دیتابیس و پیشوند جدول را مشخص می‌کند. از File Manager فایل wp-config.php سایت مربوط را باز و فقط نام پایگاه داده و مقدار پیشوند را با فهرست تطبیق دهید. این فایل شامل رمز است؛ محتوا یا تصویر کاملش را برای دیگران نفرستید. قبل از ویرایش احتمالی، نسخه امن از فایل نگه دارید.

فرض کنید برنامه دنبال wp_posts می‌گردد اما جدول‌های سایت در دیتابیس درست با پیشوند دیگری هستند. ابتدا مطمئن شوید آن جدول‌ها متعلق به همان سایت هستند؛ یک دیتابیس ممکن است اطلاعات چند نصب را در خود داشته باشد. نام صحیح را از پشتیبان، تنظیمات قبلی یا مدیر سایت تأیید کنید. تغییر اشتباه پیشوند می‌تواند سایت را به داده سایت دیگری وصل کند یا باعث نمایش درخواست نصب شود.

اگر مشخص شد فایل پیکربندی پس از انتقال اشتباه شده، اصلاح را ابتدا روی نسخه آزمایشی انجام دهید و قبل از بازکردن سایت برای کاربران، صفحه‌ها، ورود و داده‌های مربوط را تطبیق دهید. از تغییر پیشوند صرفاً بر اساس حدس خودداری کنید. ممکن است خطا مربوط به جدول اختصاصی یک افزونه باشد و پیشوند کل سایت اصلاً مشکلی نداشته باشد.

پس از انتقال میان سیستم‌ها، تفاوت Orders و orders می‌تواند مهم شود. رفتار به سیستم‌عامل و تنظیم MySQL مانند lower_case_table_names بستگی دارد؛ مستند MySQL این نکته را توضیح می‌دهد. نام داخل خطا، نام واقعی جدول و کدی را که آن را درخواست می‌کند مقایسه کنید.

راه درست ممکن است اصلاح نام استفاده‌شده در برنامه یا انتقال سازگار طبق مستندات نرم‌افزار باشد. تنظیم سراسری lower_case_table_names را روی سرور موجود بی‌برنامه تغییر ندهید؛ می‌تواند به دیگر پایگاه‌ها و قابلیت راه‌اندازی آسیب بزند. تغییر نام جدول واقعی هم بدون بررسی وابستگی‌ها و پشتیبان‌گیری مناسب نیست.

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

برای جدول یک افزونه، مستندات همان نسخه افزونه و مراحل به‌روزرسانی یا مهاجرت آن را بخوانید. نصب یا اجرای دوباره مهاجرت می‌تواند ساختار و داده‌ها را تغییر دهد؛ ابتدا روی نسخه آزمایشی و با نسخه پشتیبان انجام شود. برای جدول‌های اصلی سایت، ساخت یک جدول خالی فقط خطا را پنهان می‌کند و داده‌های از دست‌رفته را بازنمی‌گرداند.

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

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