با سلام خدمت خوانندگان عزیز.

اخیراً، من مجبور شدم پایگاه داده 1C Enterprise 8 را پس از یک خرابی که در به روز رسانی پیکربندی رخ داد، بازیابی کنم. علاوه بر این، دو بار بود و روش های مورد استفاده در طول ترمیم نیز متفاوت بود (به زودی متوجه خواهید شد که چرا). در این مقاله می خواهم در مورد روش هایی که استفاده کردم صحبت کنم.

تمام روش های در نظر گرفته شده در مقاله به نسخه سرور عملیات "1C Enterprise 8" که توسط DBMS - MS SQL 2005 استفاده می شود، اشاره دارد.

مورد شماره 1.

هنگام به روز رسانی پیکربندی، خطای "Lock تداخل" صادر شد، پیکربندی بسته شد. وقتی دوباره سعی کردم وارد پیکربندی شوم، با خطا مواجه شدم: توجه !!! هنگام تازه کردن داده ها از آخرین بازسازی، خطایی روی داد. آیا می خواهید دوباره به روز رسانی را امتحان کنید؟" "نه واقعا"

با پاسخ مثبت پیام زیر صادر شد یک عملیات ذخیره پیکربندی ناقص شناسایی شد. برای ادامه کار، باید عملیات را کامل کنید."

جستجو در اینترنت به روش زیر منجر شده است. در جدول پیکربندیاز پایگاه داده ما، شما باید خطوطی را که در آن فیلد است حذف کنید FileName = commitیا FileName = dbStruFinal یا FileName = Dynamically Updated (برای 8.3) یا FileName = dynamicCommit (8.3)و همچنین جدول را پاک کنید ConfigSave... اجازه دهید توضیح دهم که داده های جدول مسئول چه چیزی هستند: Config - این جدول پیکربندی پایگاه داده را ذخیره می کند، ConfigSave - این جدول پیکربندی کار را ذخیره می کند، یعنی. قبل از فشار دادن دکمه F7در پیکربندی

SQL Serger Managment Studio را باز کنید و با کلیک بر روی دکمه "پنجره پرس و جو را باز کنید. پرس و جو جدید»پنجره پرس و جو را باز می کند.

در پنجره درخواست ها، درخواست ها را بنویسید و آنها را اجرا کنید:

1. حذف از [OurBaseName] .. که در آن FileName = 'commit'
2. حذف از [OurBaseName] .. که در آن FileName = 'dbStruFinal'
3. حذف از [OurBaseName] .. که در آن FileName = "DynamicallyUpdated" (برای نسخه 8.3)
4. حذف از [OurBaseName] .. که در آن FileName = 'dynamicCommit' (برای نسخه 8.3)
5. حذف از [OurBaseName] ..

پس از تکمیل این درخواست ها، پیکربندی بدون مشکل شروع به کار کرد.

مورد شماره 2

دلیل خطای ورود به پیکربندی مانند مورد اول است: درگیری قفل هنگام به روز رسانی پیکربندی.

حذف ردیف های جدول پیکربندیو تمیز کردن جدول ConfigSaveتا حدی کمک کرد: پیکربندی باز شد، اما در شرکت کار نکرد فرم های مدیریت شده.

در این مورد، 2 مسیر توسعه به ذهن رسید:

1. در حال بازیابی از آرشیو در این نسخه، یک "اما" بزرگ وجود داشت: این اتفاق افتاد که آرشیو پس از به روز رسانی ایجاد شد، یعنی. آرشیو با خطا بود
2. ایده ای برای استفاده از پیکربندی یک پایگاه داده توزیع شده وجود داشت که به روز نشد، زیرا فایل برای تبادل با خطا مواجه بود.

گزینه دوم برای حل مشکل انتخاب شد. بعد، قدم به قدم به شما خواهم گفت که چه کار کردم.

1. برای مثال SQL Serger Managment Studio را باز کنید و یک پایگاه داده دلخواه ایجاد کنید پرنوس.در این دیتابیس یک جدول ایجاد می کنیم پیکربندیکسی که sql را برای انتقال داده از یک جدول به جدول دیگر نمی داند، پس MS SQL یک سرویس فوق العاده دارد. SQL Server import and Export Wizard". با استفاده از این سرویس به راحتی می توانید اطلاعات را از یک پایگاه داده به پایگاه داده دیگر انتقال دهید. برای راه اندازی این سرویس، باید دکمه " را فشار دهید ctrl + r"و در کادر محاوره ای دستور را بنویسید" dtswizard «.
   
2. ما با استفاده از سرویس انتقال می دهیم dtswizardداده های جدول پیکربندیپایگاه داده ما به جدول پیکربندیپایه پرنوس.
3. تمیز کردن میز پیکربندیدر پایگاه داده ما با استفاده از یک درخواست حذف از [OurBaseName] ..
4. در سروری که پایگاه داده توزیع شده در آن قرار دارد، سرویس را راه اندازی می کنیم dtswizardو داده ها را از جدول انتقال دهید پیکربندیفقط در یک جدول در پایگاه داده ما.

با کمک چنین اقداماتی، به سرعت و با حداقل زمان از کار افتادن معلوم شد که پایگاه داده به کار بازگرداند.

ماقبل تاریخ

دو روز پیش از 8.1 به 8.2 تغییر دادیم - confa UPP 1.2 ... را به 1.3.22.1 تغییر دادیم. بر این اساس، دسته ای از تفاوت ها با پیکربندی معمولی که رول شد - مستلزم انبوهی از خطاها بود. به مدت دو روز بدون گذراندن شب، پیکربندی را بدون توقف تغییر می دهیم. پیکربندی 15 بار در ساعت ذخیره می شود. انتظار می رفت که با ذخیره کردن، پیکربندی خراب شود، که در واقع اتفاق افتاد. چنین مشکلاتی، در conf 8.1، همیشه با خروج از کاربرانی که هنوز در پایگاه داده کار می‌کردند، حل می‌شدند، اما دیگر نمی‌توانستند دوباره با دسترسی انحصاری وارد شوند. در پیکربندی جدید 8.2 ما، پایگاه به ما گفت "خسته ام. دارم می روم")، به طور کلی، مشکل در اعلامیه توضیح داده شده است.

آنچه درست و غلط انجام شد. و راهنمایی در مورد اینکه چه کاری باید انجام شود.

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

به طور کلی، در هر سه مقاله، پاسخ به راه حل مشکل فعلی یکسان است - "بازیابی پایگاه داده از یک نسخه پشتیبان".

نیازی به صحبت در مورد اهمیت پشتیبان گیری از منظم بودن آنها و غیره نیست. من فکر می کنم که از نظر ما، این یک هشدار خوب بود، اگرچه ما یک نسخه پشتیبان از دیتابیس پس از ذخیره آن در پیکربندی 1.3 داشتیم، اما افراد کمی از نظم آنها و این واقعیت که آنها تمام شده است (و هارد دیسک درست نیست) دنبال می کنند. تمیز شده و غیره). بر این اساس، "بدیهی کاپیتان" را ببخشید، اما اگر یک نسخه پشتیبان تازه دارید، قبل از هر چیز، و شروع به بازیابی پایه از آن کنید، زمان گرانبها را هدر ندهید، که مدیریت از شما بابت زمان خرابی تشکر نخواهد کرد. با این حال، می توانید سعی کنید پایگاه "سقوط" را که به لطف اصرار من انجام شد، احیا کنید. می خواهم توجه داشته باشم که برنامه نویسان دیگری نیز تلاش کردند تا به نوعی پایه را با استفاده از روش های 1c احیا کنند، اما ناموفق بودند. من همه کارهای او را نمی دانم، اما من شاهد تلاش هایی برای راه اندازی 1C در حالت فرمان بلافاصله با راه اندازی تست و رفع امنیت اطلاعات بودم که در واقع هیچ چیزی را شروع نکرد.

من توجهم را روی SQL متمرکز کردم. من با کمی تجربه در پیکربندی و مدیریت پایگاه های داده و مجموعه ای معمولی از دستورات sql آشنا هستم، اما روشی که در زیر توضیح داده شده نیازی به دانش و مهارت عمیق کار با SQL ندارد. من فقط منطق را وصل کردم - اگر پایگاه داده در زمان ذخیره پیکربندی "افت" کند، نتیجه می گیریم که ساختار یک جدول ممکن است در SQL خراب شده باشد (اگرچه قبلاً نمی دانستم که پیکربندی در نسخه 8 در یک دنباله است. جدول) و این جدول که پیکربندی پایه در آن ذخیره شده است. و جدول با نام dbo.config. بعداً با روش "گنگ" و دوباره منطق متوجه شدم، زیرا تنها چیزی که پیدا کردم یک توسعه محلی بود که به من کمک نکرد، بلکه برای آینده مفید بود، یعنی با تشکر از نویسنده از حساب همکارم، با به کمکش دانلودش کردم بنابراین من به مهمترین چیز می پردازم - تلاش (!) برای بازیابی پایگاه داده زیرا متأسفانه نمی توانم تضمینی به شما بدهم و تعدادی از پیش تنظیم ها وجود دارد که ممکن است نداشته باشید یا همانطور که می گویند اینطور نیست. مورد شما ...

الزامات و بازیابی خود پایگاه داده.

(توجه. اگر می خواهید سعی کنید خود پیکربندی را احیا کنید حتماً به پاورقی زیر نگاه کنید. امروز (18/04/2012) من از طریق آزمایشات موفق به انجام آن شدم زیرا برای کارهای هفتگی که روی آن انجام شد متاسف شدم. بنابراین، معلوم شد که پایه را احیا می کند و پیکربندی قدیمی را بدون هیچ نسخه ای ترک می کند)

داده های اولیه - پایه SQL 1C 8.2، پیکربندی UPP 1.3.22.1 (من معتقدم روش توصیف شده برای هر مجموعه پایه 8.2 مناسب است). SQL Server 2005. خطا در اعلامیه توضیح داده شده است و خطا در زمان ذخیره تنظیمات رخ داده است! مهم ترین و واجب ترین نیاز !!! یک کپی از پایگاه داده SQL با همان پیکربندی (!) ما تبادل خودکار را با پایگاه داده دیگری پیکربندی کرده ایم و تنظیمات آنها یکسان است. علاوه بر این، از آنجایی که ما سه برنامه نویس 1C هستیم، هر کدام یک فایل پیکربندی بارگیری نشده و نسبتاً تازه دارند. در واقع، هر پایگاه داده ای مناسب است، مهم نیست با چه داده ای، نکته اصلی این است که پیکربندی موجود در آن با ساختار ابرداده پایگاه داده مطابقت دارد. من این واقعیت را متذکر می شوم که پیکربندی حتی کمی با پیکربندی که پایه بلند شد متفاوت بود. به نظر من اساسی ترین شرط این است که تفاوت های پیکربندی بر ابرداده ها تأثیر نگذارد. این واقعیت را فراموش نکنید که اگر پیکربندی متفاوت باشد، در نهایت یک پایه کار اما با پیکربندی از کپی خود دریافت خواهید کرد.

فرآیند بازیابی به خودی خود زمان زیادی را از شما نخواهد گرفت - فقط چند دقیقه، اما من به شدت توصیه می کنم از قبل حتی از پایگاه داده "افتاده" یک نسخه پشتیبان تهیه کنید، زیرا ممکن است زمان ببرد. به عنوان مثال، شما می توانید پایگاه داده را با بازگرداندن فایل log (که متأسفانه در شلوغی بازیابی آن را خراب کردیم) یا روش دیگری بازیابی کنید. بنابراین، اجازه دهید به شما یادآوری کنم که در جایی باید یک پایگاه داده SQL وجود داشته باشد، مهم نیست چه داده ای، اما با همان پیکربندی. اگر پیکربندی شما یک پیکربندی معمولی "دست نخورده" است (به این معنی که این مشکل در هنگام ایجاد یک پیکربندی معمولی جدید ایجاد شده است)، می توانید یک پایگاه داده خالی جدید ایجاد کنید و آن را با confa معمولی که قبلا داشتید پر کنید. اگر پیکربندی که پیدا کردید چندان تازه نیست - در مورد آن فکر کنید و تصمیم بگیرید، شاید تفاوت با کپی پیکربندی که باید در پایگاه داده خود تکرار کنید، زمان و منابع بسیار بیشتری نسبت به از دست دادن اطلاعات از خود پایگاه داده 1C ... نوعی شمشیر دولبه) بنابراین ...

1. با استفاده از ابزارهای SQL از پایگاه داده جمع شده یک نسخه پشتیبان تهیه می کنیم.

2. جدول dbo.config پایگاه داده خود را که confa شکسته ما در آن قرار دارد پاک می کنیم. این را می توان از SQL-Profiler انجام داد، برای مثال با اجرای دستور در آن:

حذف از.

که در آن Base2009 نام پایگاه فرو ریخته است.

توجه: در جایی از شبکه اطلاعات تأیید نشده ای را خواندم که گاهی به پاک کردن جدول dbo.ConfigSave که ظاهراً حاوی پیکربندی رول شده است کمک می کند. معلوم شد که در پایگاه داده ما خالی است، بنابراین جدول خالی را پاک نکردم. شاید - با استفاده از این جدول بتوانید به نحوی پایه 1C را فریب دهید و احیا کنید، اما با عدم اطلاع از مکانیسم عملکرد 1C با این جدول، در برنامه اقدام در رابطه با آن چیزی نخواهم گفت.

3. جدول را از پایگاه داده با کل پیکربندی در پایگاه داده آسیب دیده ما کپی کنید. در مورد من، هر دو پایگاه داده روی یک سرور قرار داشتند، بنابراین دستور کپی در SQL-Profiler به این شکل بود.

درج در .. انتخاب * از ..

که در آن base2009 نام پایه جمع شده است، BaseCopy نام پایه با یک کپی از پیکربندی است.

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

5. (کاپیتان آشکار) ما بررسی می کنیم، سیستم را برای ایجاد پشتیبان از پایگاه داده اشکال زدایی و نظارت می کنیم و بسیار مسئولانه به روند به روز رسانی پیکربندی نزدیک می شویم (این کار را نه از طریق شبکه، بلکه ترجیحاً در سرور، در صورت امکان، انجام می دهیم. داشتن یک نسخه پشتیبان اولیه). به خصوص اگر نسخه 1C شما 8.2 شده باشد. تا جایی که من از مقالات شبکه و دو روز اول کار با او فهمیدم، در مقایسه با 8.1 که هیچ مشکلی با آن وجود نداشت، حساس تر و دمدمی مزاج تر است.

5a. اگر پیکربندی پایگاه داده ای که از آن جدول confa را کپی می کنید هنوز متفاوت است (بدون تفاوت در متادیتا که قبلاً ذکر کردم) و در جایی فایل cf نسبتاً تازه شما با confa بارگیری نشده وجود دارد - آن را به پایه احیا شده قرار دهید. . در غیر این صورت، باید تمام تفاوت هایی که با کپی پیکربندی وجود داشت را تکرار کنید. بنابراین یک بار دیگر خوب فکر کنید و - آنچه مهمتر است - کار خود را در مورد تغییر پیکربندی (و اینکه چقدر زمان صرف آن خواهید کرد) یا کار کاربران پایگاه داده تا آخرین نسخه پشتیبان را تجزیه و تحلیل کنید. در مورد من، کار 2 برنامه نویس به مدت 3 ساعت در مقابل کار حدود 100 کاربر برای 1.5 روز بود، بنابراین انتخاب واضح بود.

ZY اجازه بدهید دوباره به شما یادآوری کنم؟ که این عملکرد بازیابی یک روش 1C-sheep غیرمستند برای بازیابی پایه است (در مورد خاص فروپاشی پایه که در حین ذخیره confa رخ داده است) و هر کاری که انجام می دهید - با خطر و خطر خود انجام می دهید، اما به طور خاص در در مورد من، راه های دیگری برای احیای پایگاه وجود دارد که حداقل اطلاعات موجود را از دست نداده است (فایل لاگ پاک شده است و آخرین نسخه پشتیبان نشان دهنده از دست دادن 1.5 روز کار حدود 100 کاربر است)، بنابراین، همانطور که می گویند ، پل ها سوختند)

ZYY این اولین نوشته من در اینجا است. در سایر انجمن های 1C مالش دهید، اما من این منبع را از نظر پیشرفت ها و انتشارات منتشر شده یکی از مفیدترین منابع می دانم، بنابراین برای بسیاری از IF ها در این نشریه به شدت قضاوت نکنید). من بسیار خوشحال خواهم شد اگر واقعاً به کسی در بازسازی پایگاه ویران شده کمک کنم ، زیرا فقط جنگ هسته ای بدتر از آن است)

ZYYYY بعد از 3 هفته مشکل دوباره تکرار شد) این بار چند ثانیه حل شد (اگر زمان تهیه نسخه پشتیبان را در نظر نگیریم) و حتی کاربران مجبور به بیرون راندن نشدند.

_____________________________________________________________________________________________________________

یکی از همکاران امروز دوان دوان آمد. همون دردسر فقط پایه آزمایشی است و نه خود پایه کار، و خود بیس تا آنجا که - اما پیکربندی برای او مهم است. به مدت یک هفته او یک هفته را صرف آن کرد، هرگز آن را در یک فایل cf آپلود نکرد و تغییرات را در پایگاه کاری آپلود نکرد. خوب - چرا میز را عمیق تر نمی کنید؟ این بار حتی راحت تر است. من SQL Managment Studio را باز می کنم. من یک پرس و جو در جدول برای فیلدهایی با تاریخ فعلی تغییر و زمانی که پایه پرواز کرد تشکیل می دهم - نتیجه 2 رکورد می دهد. اول - Field FileName = "commit" خوب - این رکورد را بزنید - و همه چیز برای من درست شد! پیکربندی زنده شد و پایه دوباره کار می کند. چه باید انجام شود ؟!

بنابراین، در پنجره باز SQL Managment Studio، ما به دنبال پایگاه داده خود هستیم - جداول را باز کنید، به دنبال جدولی با confa در انتهای لیست باشید. dbo.configروی میز - دکمه سمت راست - میز باز... علاوه بر این، در پنجره سمت راست، در خود جدول به ترتیب حروف الفبا به قسمتی که FileName = "commit" است، بروید. ما روی این ورودی ایستاده ایم - دکمه سمت راست ماوس - حذف.به طور کلی، ورودی را با فایل باینری حذف کنید. در مرحله بعد سعی می کنیم به تنظیمات مربوطه برویم. خطا همان است که ابتدا ظاهر می شود. احتمالاً کار نکرد؟ خوب... و سپس، قبل از صدور مانند قبل پیام دوم در مورد عدم امکان ذخیره - کامپیوتر در مورد آن فکر کرد. بعد از 30 ثانیه - در مورد معجزه! پیکربندی باز شده است. سعی می کنیم پیکربندی را ذخیره کنیم (پس از ذخیره فایل cf). پیکربندی ذخیره شده است. بنابراین، گرگ ها تغذیه می شوند و گوسفندها در امان هستند. من در مورد عملکرد کامل پایگاه پس از چنین سوء استفاده هایی مطمئن نیستم - بنابراین به شما توصیه می کنم که بعد از ظهر (البته پس از ایجاد بایگانی) نتایج را بازسازی و دوباره محاسبه کنید. بهبودی مبارک و احساسات مثبت)

جعبه شنی

1C، بازیابی پیکربندی پایگاه اطلاعاتی با استفاده از MS SQL

یک بار با مشکلی مواجه شدم: هنگام به روز رسانی پیکربندی از مخزن، یک شکست رخ داد و 1C بسته شد.

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

زیرا این مشکل بیش از یک بار به وجود آمده است. تصمیم گرفتم یک گزینه درمانی را به اشتراک بگذارم.

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

هنگام تجزیه و تحلیل این مشکل، چندین گزینه برای حل مشکل پیدا شد که هر راه حل در موارد مختلف کار می کند.

گزینه 1 (اگر یک نسخه پشتیبان SQL با یک کپی با پیکربندی یکسان دارید):

یک کپی از امنیت اطلاعات مستقر شده است و یک درخواست از ساختار زیر اجرا می شود:
استفاده از GO DELETE FROM .. GO INSERT INTO .. ​​SELECT * FROM .. GO
در این حالت، جدولی که پیکربندی IB در آن ذخیره شده است دوباره پر می شود. توصیه می شود پس از این عملیات امنیت اطلاعات را تست و تصحیح کنید.

گزینه 2 (در صورت عدم وجود نسخه پشتیبان):

با این گزینه مانند آخرین نی برخورد شد. زیرا پیکربندی در حال توسعه بود و نسخه پشتیبان با تکیه بر مخزن کمی فراموش شد.
در پایگاه داده، دو رکورد از جدول "Config" با مقدار موجود در ستون "FileName" - dbStruFinal حذف می شود و commit می شود.

کوئری زیر اجرا می شود:
از GO DELETE FROM استفاده کنید. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
به اندازه کافی عجیب، پایه زنده می شود.

برچسب‌ها: 1c enterprise 8.2، SQL، بازیابی پیکربندی

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

جعبه شنی

1C، بازیابی پیکربندی پایگاه اطلاعاتی با استفاده از MS SQL

• مایکروسافت SQL Server،
• مدیریت پایگاه داده

یک بار با مشکلی مواجه شدم: هنگام به روز رسانی پیکربندی از مخزن، یک شکست رخ داد و 1C بسته شد.

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

زیرا این مشکل بیش از یک بار به وجود آمده است. تصمیم گرفتم یک گزینه درمانی را به اشتراک بگذارم.

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

هنگام تجزیه و تحلیل این مشکل، چندین گزینه برای حل مشکل پیدا شد که هر راه حل در موارد مختلف کار می کند.

گزینه 1 (اگر یک نسخه پشتیبان SQL با یک کپی با پیکربندی یکسان دارید):

یک کپی از امنیت اطلاعات مستقر شده است و یک درخواست از ساختار زیر اجرا می شود:
استفاده از GO DELETE FROM .. GO INSERT INTO .. ​​SELECT * FROM .. GO
در این حالت، جدولی که پیکربندی IB در آن ذخیره شده است دوباره پر می شود. توصیه می شود پس از این عملیات امنیت اطلاعات را تست و تصحیح کنید.

گزینه 2 (در صورت عدم وجود نسخه پشتیبان):

با این گزینه مانند آخرین نی برخورد شد. زیرا پیکربندی در حال توسعه بود و نسخه پشتیبان با تکیه بر مخزن کمی فراموش شد.
در پایگاه داده، دو رکورد از جدول "Config" با مقدار موجود در ستون "FileName" - dbStruFinal حذف می شود و commit می شود.

کوئری زیر اجرا می شود:
از GO DELETE FROM استفاده کنید. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
به اندازه کافی عجیب، پایه زنده می شود.

برچسب‌ها: 1c enterprise 8.2، SQL، بازیابی پیکربندی

این مقاله قابل اظهار نظر نیست، زیرا نویسنده آن هنوز اظهار نظر نکرده است تمام عیارعضو جامعه فقط پس از دریافت نویسنده می توانید با او تماس بگیرید