Найчастіші помилки «1С» та методи їх виправлення. Найчастіші помилки «1С» та методи їх виправлення Збій програми 1с втрата даних звіти

Навряд чи хтось посперечається, що 1С:Підприємство загалом програма непогана. Адже погана програма навряд чи стала б такою популярною. І Ви як користувач напевно звикли до неї і знаєте її досить добре, з усіма плюсами та мінусами. Але будь-якій програмі, хорошій чи поганій все-таки зазвичай притаманні глюки.

Давайте розберемося спочатку терміном «глюк». Слово глюк своїм корінням перегукується галюцинація, тобто. щось, що здається. Втім, на відміну від галюцинацій, глюки в програмах штука на жаль цілком реальна. Глюк - це загалом збій програми, який може бути регулярним або одноразовим (до речі другі - найбільш неприємні).

Глюки бувають пов'язані або з помилками в програмному коді, або з помилками зі збоями в апаратній частині, ну, наприклад, стрибнула напруга, чогось загубилося в пам'яті і ось вам результат, програма не працює. Бувають і всілякі гібридні варіанти, тобто. одному комп'ютері програма працює, але в іншому глючить.

До речі, часто купуючи комп'ютер, ми не замислюємося, який у ньому стоїть блок живлення. А даремно. Більшість апаратних збоїв пов'язані з дешевим і як наслідок поганим блоком живлення. Адже недарма, середній корпус з блоком живлення коштує близько 30-40 доларів, а хороший блок живлення окремо коштує від 40. А хороше джерело безперебійного живлення теж недешеве, так само як і хороший мережевий фільтр. Але це ліричний відступ від основної теми.

Особистий досвід показує, що 1С:Підприємство найкраще працює на гарній апаратурі, а особливо на термінальних серверах високого класу. Це пов'язано з тим, що дорогі сервери коштують так дорого не тільки через те, що вони зібрані на швидких процесорах і жорстких дисках, а ще й з тієї причини, що сервери застосовують, в першу чергу, надійні блоки живлення, процесори, пам'ять, жорсткі диски.

На таких комп'ютерах рідко трапляються вильоти з помилками під час роботи.

Втім, і на такій апаратурі помилки трапляються. Причому, на жаль, це помилки, які переходять з версії до версії технологічної платформи 7.7. і схоже розробники виправляти їх не збираються, хоча добре знають про них. Тому нам залишається лише уникати їх.

Насправді поширених та відомих глюків у 1С:Підприємство небагато. Все ж таки програмі вже більше 7 років і за цей час розробники випустили аж 25 релізів, таким чином виправивши більшість помилок.

Ну, власне, давайте подивимося на глюки:

• Однією з частих помилок є така. Під час роботи в 1С:Підприємство вона раптом ні з чого вилітає з помилкою. "Програма виконала неприпустиму помилку і буде завершена". Через що сталася така помилка, як правило, незрозуміло, оскільки носять вони одноразовий характер.

Рішення: якщо ж помилка повторюється за певної ситуації, потрібно передати інформацію про неї підприємству, яке обслуговує вашу фірму. Такі помилки зазвичай пов'язані з апаратними збоями чи збоями операційної системи.

• Неможливість збереження архівної копії (з конфігуратора) на зовнішні носії (флеш-пам'ять, магнітооптичні диски тощо). Виявляється в такий спосіб. При збереженні прямо на зовнішній носій після закінчення процесу видає помилку «Помилка визначення вільного місця на диску» і нічого не зберігає. Помилка також виникає при розвантаженні даних, а також при розвантаженні для обміну з базами, при використанні УРІБ. В останньому релізі платформи помилка виправлена, проте іноді, як і раніше, виникає з деякими операційними системами.

Рішення:зберігати спочатку на жорсткий диск (мережа), а потім копіювати зовнішній носій. Незручно, але подітися нема куди.

• «Зависання» під час тестування та виправлення ІБ. Якщо ви запускали процедуру тестування/виправлення з конфігуратора, то могли звернути увагу, що варто переключитися з конфігуратора в іншу програму, а потім назад, то ми вже не бачимо, що відбувається. Програма начебто зависає. Насправді, вона продовжує працювати, але ми не бачимо прогресу. Пояснення громадської організації САБ щодо цього не смертельного, але неприємного глюку нагадують пояснення головного героя фільму «Люди в чорному», дозволю собі приблизно процитувати: «Місячне світло відбилося від Венери, що викликало вибух болотного газу». Тобто. нормальній людині ці пояснення незрозумілі. Вони взагалі незрозумілі і комп'ютерному фахівцю. 1С:Підприємство говорить так, цитую: «Це пов'язано з особливостями взаємодії бібліотеки mfc32.dll з Windows». Помилка виникає у версії Windows починаючи з Windows XP.

• «Вилітання» 1С:Підприємство з помилкою під час старту. Власне, тут сама програма не винна. Тут можливі різні варіанти, але зазвичай пов'язано це з тим, що на диску комп'ютера є помилки. Як правило, це втрачені кластери.

Рішення:В цьому випадку пробуємо зробити наступне - виконуємо перевірку диска, якщо це не допомогло, то заходимо через Мій комп'ютер до базової папки. У ній міститься папка SYSLOG. Видаляємо цю папку. Таким чином ми втрачаємо журнал реєстрації, зате 1С:Підприємство працюватиме. Якщо це не допомогло, потрібно шукати проблему в іншому місці. Ця помилка мабуть найнеприємніша і небезпечна оскільки завдяки їй, можна втратити півдня, а то й день роботи.

• Втрата даних при відновленні послідовності. А ось це вже дуже неприємна помилка. Виникає вона у конфігураціях, у яких немає компоненти «Оперативний облік», тобто. «Бухгалтерський облік для України», «Бюджетна для України», «Підрядник будiвництва», «Рарус громадське харчування» та ін. дії, виконані користувачем у базі, не будуть збережені при виході! Тобто. запустили ми, проведення, не через Сервіс-Обробка документів, а через Дії-Проведення документів, і якийсь із документів не провівся. Припустимо, ми його виправили. Так от, якщо ми вийдемо із програми, то всі виправлення будуть втрачені. Помилка немає у змінах «ПУБ», «Комплексна», «Торгівля і склад», тобто. там, де є компонент «Оперативний облік».

Вочевидь, природа помилки пов'язані з тим, що з прискорення проведення документів проводить в транзакції. Проведення через Дії-Проведення документів працює швидше, ніж Обробка документів з меню Сервіс. При помилці під час проведення транзакція не завершується і надалі компанія вважає, що ми всі наші дії виконуємо у тій самій транзакції. І при завершенні роботи програми 1С:Підприємство транзакцію не фіксує.

Помилка також добре відома розробникам.

Рішення:Не скористатися Проведенням документів з меню Дії. Або при помилці, при такому проведенні, виконувати вихід із 1С:Підприємство, вхід до неї, а вже потім вносити зміни.

• Наступна помилка виникає вже, коли ми користуємось Сервіс - Обробка документів. Помилка спостерігалася лише у Windows 2003 Server. Полягає в наступному: при перенесенні документа зі списку, що проводяться до списку, що не проводяться (кнопки -> і =>>), виникає помилка «Invalid argument encountered». При натисканні кнопки ОК програма наглухо зависає, хоча вдає, що щось робить. Помилка у принципі повторювана, але виникає регулярно, тобто. не обов'язково вона виникне з першого натискання, але буває так. Інформація про помилку також передавалася розробникам.

Рішення:Власне, рішення немає. Сподіватися, що помилки не виникне.

• Тепер мабуть найвідоміша помилка платформи. Неможливість збереження в Excel звітів великого розміру. Суть помилки в тому, що при спробі зберегти великий звіт із 1С:Підприємство у форматі Excel, програма просто зависає. Причому це не виглядає так, ніби час збереження Excel залежить безпосередньо від розміру файлу. Просто при досягненні певного розміру файли не зберігаються. У форматі mxl (внутрішній формат таблиць програми) файл зберігається успішно. Але спроба відкрити його в Excel (за допомогою конвертера mxl2xls, що поставляється окремо) також не увінчується успіхом, і веде до зависання Excel. Помилка виявлена ​​дуже давно і відома відома розробникам. Найнеприємніше, що у версії 8.0 вона вже виправлена, отже помилка не настільки критична, що не піддається виправленню, але розробники чомусь не хочуть виправляти.

Рішення:рішення тут немає. Або формувати звіт шматочками або попросити програміста, щоб він переписав звіт таким чином, щоб він одразу формувався в Excel. Правда, у другому випадку Excel обов'язково має бути встановлений на комп'ютері.

• Наступна помилка досить не серйозна і страждають від неї переважно програмісти. Суть її полягає в тому, що якщо ми копіюємо текст, або таблицю через буфер обміну Windows і при цьому в тій програмі, з якої ми копіюємо зараз, стоїть англійська мова, то в ту програму, в яку ми копіюємо російську (українську) текст буде вставлений як символи розширеної латиниці.

Рішення:Не забувати перемикати мову не російську.

Насамкінець хочу сказати, що незважаючи на всі помилки, 1С:Підприємство програма все-таки непогана і зі своїм завданням справляється. Якби ще розробники оперативніше реагували на інформацію про помилки... Втім їх теж можна зрозуміти. Як не крути, а 7.7. - уже минуле, яке підтримується за інерцією, Зараз 1С:Підприємство впритул зайняте 8.2. Але це вже інша програма та зовсім інші глюки.

Ця стаття є продовженням циклу статей «Перші кроки до 1С». У ній розглянуто типові прийоми відновлення бази 1С на платформі «1С:Підприємство 8» після збоїв. Передбачається, що база працює у файловому режимі. Відновлення бази клієнт-серверному режимі роботи розглядається, т.к. дане питання явно виходить за рамки "перших" кроків фахівця-початківця.

Матеріал статті детально розкриє відповіді на такі питання:

• Що робити до початку всіх робіт з відновлення? (копію, Карле!)
• Які тонкощі є під час використання утиліти перевірки?
• Які засоби для відновлення є у конфігураторі?
• Коли і навіщо робити вивантаження/завантаження у формат *.dt?
• Якщо все вищеописане не допомогло, що можна спробувати?

Застосовність

Стаття написана для платформи «1С:Підприємство» версії 8.3.4.496, але не переживайте, якщо ви працюєте з старшою версією! Весь матеріал є абсолютно актуальним.

Як у 1С відновити пошкоджену базу «1С:Підприємство 8»

Часом для новачка це завдання здається просто нереальним. Хоча, насправді, є ряд нехитрих штатних засобів тестування баз 1С і прийомів виправлення помилок, що виникають.

Поява різноманітних систематичних збоїв (помилок, невірно відображуваних даних, аварійне закриття програми) можна вважати пошкодженням бази.

Причини виникнення критичних помилок бувають різноманітними. Найчастіше проблеми виникають через збої електроживлення.

З упевненістю можна сказати, що при клієнт-серверному режимі роботи база більш стійка до помилок.

В рамках наших статей ми будемо розглядати файловий режим роботи бази. І перше, що потрібно попередити клієнта – наявність джерела безперебійного живлення на комп'ютері, де встановлена ​​інформаційна база, дуже бажано.

Отже, головне не лякатися перед спробою відновлення бази зробити її копію.

Наприклад, можна спочатку скопіювати всю папку, в якій розміщена база, а потім у цій папці залишити лише файл 1Cv8.1CD (файл бази) та папку 1Cv8Log (журнал реєстрації подій).

Насправді, здебільшого бази підлягають відновленню. Деякі 1С-ники це зрозуміли і радо перехоплюють таких клієнтів. Самому робити здебільшого нічого особливого не треба, клієнт наляканий, а робота тестових програм займає чималий час.

Перейдемо до практики. Спочатку з'ясуйте у клієнта, як давно і за яких обставин почали виникати збої. Дізнайтеся, як користувачі здійснюють оновлення конфігурації та як за часом пов'язані ці дві події. Уточніть об'єм бази.

Навіть якщо в даному конкретному випадку з'ясовані обставини вирішально на Ваші наступні дії не вплинуть, Ви зможете зібрати деяку статистику, яка може стати в нагоді в майбутньому.

Обов'язково дізнайтеся, чи оновлювалася платформа, і під яким релізом платформи база працювала раніше.

Насамперед видаліть усі файли та папки, які у заданій директорії оточують файл бази (1Cv8.1CD). Так, це деякі службові файли, які забезпечують повноцінну роботу, але точно зазначено, що у роботі цих файлів виникає деяке неузгодженість.

Нічого страшного не станеться, тому що при черговому запуску бази всі необхідні файли будуть створені заново. Із запуском ми поки що почекаємо.

Тепер використовуємо найефективніший, але ще далеко не останній засіб. У директорії C:\Program Files\1cv82 (для платформи 8.3 – 1cv8)\(далі номер релізу платформи)\binзапустіть утиліту chdbfl.exe

Увага! У кожному релізі платформи є власна утиліта chdbfl.exe. Доцільно використовувати утиліту з релізу платформи, з яким використовувалася дана база. Найчастіше – це останній встановлений реліз платформи.

Тут варто сказати про одну особливість, якщо момент пошкодження бази приблизно збігається з моментом оновлення платформи, то утиліта chdbfl.exe попередньої платформи найчастіше дає кращі результати в пошуку та виправленні помилок.

Особливість даної утиліти - якщо при першому проході виправлених помилок не було (утиліта не змогла виправити жодної помилки), то повторно запускати її, можна сказати, марно.

Однак якщо помилки виправлені не всі, але при цьому відзначається зменшення кількості помилок, то є сенс запустити утиліту ще раз.

Були випадки, що за другий прохід кількість знайдених помилок змінювалася нанівець. Одним словом, повторюйте операцію, доки є результат зменшення кількості помилок. Схоже, що частина виправлених помилок при черговому проході дозволяє виправити ще й інші.

Самі параметри тестування та виправлення, якщо Ви абсолютно чітко не розумієте, що саме робите, краще не чіпати.

Поліпшення результатів тестування при повторному використанні цього засобу не відзначено.

Слід сказати про засіб перевірки конфігурації. За досвідом, помилки, що відзначаються цим засобом, не відрізняються особливою критичністю. Швидше вони просто уповільнюють роботу самої бази. Що, по суті, для баз розміром понад 4 Гб користувач може розцінюватися теж як пошкодження бази.

4 Гб - це максимально допустимий розмір не самої бази, а таблиці в базі. Але який-небудь регістр може бути значно більше інших і займати більшу частину обсягу бази.

У цій формі без абсолютно чіткого розуміння ніяких налаштувань змінювати не варто.

Слід сказати ще про один не зовсім очевидний метод. Справа в тому, що при розвантаженні бази в файл з розширенням dt існує дуже низька ймовірність, що завантажити його назад не вдасться.

Однак при завантаженні відбувається певна реструктуризація пам'яті, що в окремих випадках дозволяє відновити роботу бази шляхом послідовного вивантаження та завантаження.

Якщо після всіх проведених заходів та випробувань Ви виявили, що Ваша база залишається пошкодженою, то доцільно використовувати цей засіб.

Вивантаження здійснюється в конфігураторі через меню Адміністрація, пункт Вивантажити інформаційну базу.

З'явиться діалогове вікно, в якому потрібно буде вказати напрямок вивантаження. Назва файлу, що створюється, можна використовувати за замовчуванням – 1Cv8.dt.

Слід зазначити, що вивантаження також є одним із можливих методів копіювання.

Завантаження найкраще робити у нову базу без конфігурації. Для створення такої бази у вікні інформаційних баз натисніть кнопку Додати. На черговому кроці збережіть налаштування Створення нової інформаційної базита натисніть на кнопку Далі.

У формі, що з'явилася, поміняйте налаштування на Створення інформаційної бази без конфігураціїа також натисніть кнопку Далі. На наступних двох кроках визначте ім'я бази та директорію (порожню), в якій вона буде.

Додаткові параметри можна не заповнювати та натиснути на кнопку Готово. Буде створено інформаційну базу без конфігурації.

Ще кілька моментів. Якщо несправності в роботі бази спостерігаються лише на одному комп'ютері, слід спробувати змінити комп'ютер. Якщо несправності виявляються лише в одного користувача, слід спробувати перестворити користувача.

Іноді допомагає видалення бази зі списку у вікні інформаційних баз із подальшим додаванням до списку тієї ж існуючої інформаційної бази (відновлення шляху до неї).

Насамкінець хочеться сказати, що, звичайно, не всі бази підлягають відновленню, частина з них відновлюється складнішими способами. Але не засмучуйтесь, такі випадки бувають досить рідко.

Як профілактика можна порадити проводити оновлення баз через конфігуратор і використовувати штатні засоби тестування та виправлення помилок перед кожним оновленням. Користувачі, які є власниками базових версій та мають право на безкоштовне оновлення, також можуть завантажувати файли оновлення з сайту.

У наступній статті розглянемо можливості настроювання списку інформаційних баз.

Програмні продукти 1С створені для оптимізації діяльності підприємства, і збої у роботі перешкоджають нормальному перебігу робочих процесів у створенні. У гіршому випадку проблеми в роботі програми можуть викликати повну зупинку діяльності окремих структур компанії: бухгалтерії, фінансового відділу, кадрової служби, виробництва та багатьох інших. Навіть якщо збій має короткочасний характер, він може на якийсь час обмежити доступ до важливих документів. У зв'язку з цим оперативність усунення проблеми виходить першому плані. З одними проблемами співробітник, навчений роботі з продуктами 1С, може впоратися самостійно. Інші ж вимагають кваліфікованої допомоги спеціаліста із сервісного центру. Розберемо основні причини збоїв у роботі 1С та способи її відновлення.

Алгоритм дії при виявленні неполадок має виглядати так:

• Визначення помилки та її причини. Оперативність дій цьому етапі допоможе уникнути витрат часу надалі. Іноді безсистемні дії співробітників, чия програма перестала функціонувати, лише посилюють проблему, але з вирішують її.
• Відтворення збою. Моделювання помилки необхідне складання грамотної стратегії з її виправленню.
• Виправлення помилки. Коли тестування показало, що інтерпретацію помилки було здійснено правильно, до роботи може розпочати 1C спеціаліст, відповідальний вирішення проблем з 1С. Наприклад, якщо ви використовуєте програму «1С: Підприємство», підтримка цього рішення здійснюватиметься співробітниками сервісного центру, з яким ви уклали договір.

Помилки у роботі 1С можна класифікувати так:

1. Помилки користувача. Ці помилки викликаються некоректними діями співробітника і найчастіше є наслідком недостатнього знання специфіки програми 1C. Найбільш поширені помилки цього типу – неправильне створення документа, неправильне використання функціоналу програми, випадкове блокування 1С тощо. Для запобігання появі такої проблеми в майбутньому рекомендується проведення навчання для всіх співробітників, які мають доступ до 1С. Це може бути як корпоративне навчання спеціалістів ліцензованих центрів підтримки, так і самостійне навчання з використанням тематичної літератури.

2. Програмні помилки. Найбільш поширені збої цієї категорії:

• Помилки під час запуску програми можуть бути викликані відсутністю ключа захисту, збоями локальної мережі або порушенням структури конфігурації.
• Помилки при встановленні найчастіше є наслідком неправильно введеного ключа.
• Помилки при оновленні – найпоширеніші програмні помилки, викликані несвоєчасним оновленням компонентів програми.

Для вирішення програмних помилок необхідно скористатися послугами спеціаліста з роботи з продуктами 1С.

3. Технічні помилки. Ці помилки зазвичай пов'язані з несправним чи проблемним обладнанням. Наприклад, повільна робота програми може бути викликана недостатньою потужністю сервера. Щоб усунути цю проблему, необхідно проконсультуватися з ІТ фахівцями та дотримуватися їх рекомендацій.

Причин виникнення таких помилок може бути безліч. Перше, що має сенс робити у разі таких помилок — визначитися з джерелом проблеми.

Уточнити обставини та терміни появи помилки: несправність, яка не може бути відтворена, можливо, є просто випадковістю, збоєм.

Перевірити роботу програми з іншого комп'ютера та іншого облікового запису користувача.

Перевірити релізи платформи та конфігурації: чи відповідає поточна версія останньої офіційної.

Надалі, якщо ви не впораєтеся з помилкою самостійно, вам треба буде пояснити природу її появи фахівцеві, відповідно ці питання виникнуть у будь-якому випадку.

Існує низка помилок, які виникають під час використання неліцензійного програмного забезпечення (як продуктів «1 °C», так і, наприклад, операційної системи «Windows»). Характерний приклад у разі «ламаної» платформи «1С»: патч, що зламує конкретну версію платформи, перестає працювати після встановлення нової версії платформи, вхід до бази в цьому випадку призведе до появи повідомлення «Не виявлено вільної ліцензії».

Важливо!Не забувайте робити резервну копію ваших баз перш ніж змінювати будь-що в конфігурації. Якщо база не відкривається за допомогою конфігуратора, слід скопіювати папку з базою засобами операційної системи і далі виконувати всі операції з цією копією.

Версії змін мають бути актуальні (це особливо важливо у разі змін, основі яких створюється регламентована звітність). Оновлення до поточної версії буде першим кроком усіх без винятку фахівців-розробників, якщо ви звернетеся до них. Після перевірки актуальності версій конфігурацій слід перевірити актуальність релізу платформи (тут слід враховувати рекомендації «1С»: в повному обсязі релізи змін відповідають релізам платформи).

1с Підприємство. 1с Бухгалтерія. Якщо 1С спіткнулася?

Фахівці фірми "Поліком Про"

Даним матеріалом ми починаємо невеликий цикл статей, присвячених особливостям роботи з такими популярними, але непростими пакетами, як 1C Підприємство та 1C Бухгалтерія. Можливо, ці статті допоможуть вам вирішити деякі нагальні проблеми із встановленням та налаштуванням цього програмного забезпечення.

Як відомо, "не помиляється лише той, хто нічого не робить". Чого тут гріха таїти, трапляється так, що робоча конячка 1С спотикається. Втім, задля справедливості варто відзначити, що це ніколи не відбувається без вагомих на те підстав. Для того, щоб позбавитися проблеми, необхідно почати з визначення причин її виникнення.

Основні причини збоїв:

некоректна робота операційної системи;

Перепади або імпульсні перешкоди електроживлення;

Неправильна дія користувача, точніше сказати, помилка у конфігурації, яка дозволила користувачу вчинити неправильну дію;

Комп'ютерні віруси

Реакція на перелічені проблеми може виражатися у неприємних симптомах:

База не завантажується, видає повідомлення про помилки;

База вантажиться, але звіти, які мають давати однакові результати, не сходяться;

Результати у звітах змінилися порівняно з тими, що їх раніше видавала програма;

Наприкінці попереднього періоду залишки є, але в початок наступного його періоду - залишків немає.

І так далі. Цей список можна продовжувати нескінченно. Втім, практично будь-які подібні неприємності можна усунути, зробивши низку нехитрих дій. Отже, поговоримо про те, як можна вилікувати базу даних вашого 1C.

1. Для початку зробіть копію інформаційної бази. Перше правило медицини: "Не нашкодь"! Існування резервної бази дозволить вам будь-якої миті часу зробити відкат, повернувши все на круги своя. Копію створити елементарно - просто скопіюйте папку з базою в інше місце для проведення над нею оздоровчих експериментів.

2. Підключіться до копії бази в режимі "Конфігуратор". Виберіть "Адміністрування" - "Тестування ІБ". Погоджуйтесь із установками тестування за умовчанням:

"Реіндексація" - Так;

"Перевірка логічної цілісності" - Так;

"Перевірка фізичної цілісності" - Так;

"Перерахунок службових даних" - Так;

"Перерахунок підсумків" - Так;

"Упаковка таблиць інформаційної бази" - Ні;

"Тестування та виправлення" - Так.

Ця чудова процедура допомагає у 80 випадках зі 100. Її слід проводити регулярно, як ранкову гімнастику, навіть якщо ви не помічаєте проблем із вашою 1С базою. Щомісячне виконання цієї процедури є цілком розумним засобом більшості хвороб.

3. Що робити, якщо "1С: Підприємство" взагалі не запускається, навіть у режимі Конфігуратора? Тоді, швидше за все, збій стався у конфігураційних файлах (1Cv7.md). Зазвичай причиною подібних катаклізмів є перепади напруги або збої мережі при збереженні конфігурації. Головною ознакою збою у файлі конфігурації є повідомлення: "Загальна файлова помилка при доступі до файлу C: Windows\Temp:" в момент запуску "1С: Підприємства".

У цьому випадку можна спробувати замінити файли з розширенням md і dd на ті, що зберігаються в архіві (звичайно, архів має бути свіжим, з останніми змінами вашої конфігурації). Якщо архіву немає, то є шанс знайти ці файли в папці NewStru, яка, як правило, є в папці з вашою базою "NewStru". Ця папка з'являється в той момент, коли після завершення налаштування зберігаєте виправлену конфігурацію. У цей момент якраз і відбувається перезапис тих файлів md, dd і dbf, які торкнулися зміни конфігурації. Система не виправляє оригінали файлів. Вона спочатку все записує в каталог NewStru, а потім, якщо все пройшло вдало, оновлені файли копіюються в основну базу. Таким чином, завдяки 1С всі файли в NewStru зберігаються!

4. Якщо після численних спроб вам так і не вдалося зайти в конфігуратор - вхід (а точніше, вихід) залишається тільки один. Необхідно цей найгірший md-файл відправити електронною поштою на адресу [email protected]. У тексті листа необхідно вказати номер вашої реєстраційної анкети або код партнера. Не забудьте точно вказати симптоми, які, як вам здається, говорять про те, що файл зіпсувався. "Хотлайн" - місце, де допоможуть вилікувати ваші пошкоджені md-файли.

5. Що робити, якщо конфігурація завантажується, а "тестування та виправлення" бази не допомагає? Тоді рекомендується "Вивантажити" базу та "Завантажити" назад. Це можна зробити в конфігураторі меню "Адміністрування". Дуже дієва процедура. Тільки намагайтеся не переплутати її з функціями "Зберегти..." та "Відновити...". При розвантаженні система аналізує внутрішню структуру даних і вибирає ті дані, що їй зрозумілі і є правильними з її точки зору. В результаті вивантажується лише те, що працює на 100%. Те, що невизначене для системи, вона просто ігнорує. Ви отримуєте можливість завантажити на всі сто відсотків вірні дані. Є, щоправда, і істотний недолік - неможливо дізнатися, що саме система проігнорувала. Це рівнозначно втрати частини даних. Втім, краще втратити лише частину даних, ніж взагалі все.

6. Якщо після виконання вищезгаданих процедур проблеми все ще збереглися, потрібно перенести з бази папки всіх користувачів разом із папкою UserDef. Кілька разів я стикався з проблемами саме через них. Зробити це не складно: потрібно видалити старі папки і, якщо все працює, створити нові.

7. Якщо збій стався не з вини стихійних лих, тобто методика аварійного відновлення не допомагає вирішити проблеми, що виникають, потрібно спробувати згадати, які дії здійснювалися над комп'ютером і базою. Спробуйте здійснити відкат назад - до стану, в якому база ще функціонувала.

8. Ще один спосіб – почати переміщати базу з місця на місце. Перенесіть її на інший комп'ютер, на іншу операційну систему... Крім цього, базу можна переставити на інший "реліз" двигуна (зараз 19 "реліз" - для тих, хто не знає). Зміна "релізу" іноді дуже допомагає, але не рекомендую вам здійснювати відкат на далекі номери "релізів": можна перейти з 18 на 17 або 19, але ніяк не на 8 "реліз". Значний перескок із номера на номер може, навпаки, зашкодити. Почати варто просто з переустановки 1С того самого "релізу". (Неписане правило: зберігайте інсталяції старих "релізів", оскільки вони можуть стати в нагоді).

9. Якщо ви не можете зайти до бази, отримуючи повідомлення про помилку у файлі dbf, і при цьому тестування бази не допомагає, то в цьому випадку можна спробувати використовувати "зовнішню" утиліту для лікування dbf-файлів. Ви легко зможете знайти з десяток таких програм в інтернеті, наприклад "dbfix".

10. Однією з найпоширеніших причин усіх бід є відсутність місця на диску.

Боротьба за відновлення даних - не найприємніше заняття. Щоб уникнути виникнення подібних проблем, необхідно постаратися усунути всі можливі причини їх появи. Запобіжних заходів не так вже й багато.

Що треба робити, щоби не було збоїв?

1. Архівуйте інформацію.

Від будь-яких бід може врятувати архівацію даних.

Необхідно регулярно робити резервну копію інформаційної бази вашої 1С.

Увага! Краще робити копію бази не тому ж жорсткому диску, де розташована робоча база, але в окремому пристрої записи: стрічковий стример, ZIP, CD-RW, окремий жорсткий диск.

Увага! Зробіть процес архівування інформації автоматичним, не довіряйте собі чи іншим виконавцям - людині властиві провали у пам'яті. Наприклад, для автоматизації архівування інформації 1С є дві дуже зручні і недорогі програми "Гендальф Хранитель" та "Ікс Стражник".

2. Забезпечте стабільне живлення.

Для сервера (комп'ютер, де знаходиться інформаційна база 1С) використовуйте джерело безперебійного живлення (UPS), найкраще моделі зі стабілізацією напруги. Робочі станції можна підключати до мережі через недорогі "мережеві фільтри" (близько $13), але ще краще їх також включати через системи безперебійного живлення.

3. Правильний вибір системної платформи.

Якщо розмір інформаційної бази більше 200 Мб або з нею працює більше трьох користувачів, необхідно використовувати серверні операційні системи Windows 2000 Server, Windosw NT 4.0, Novell Netware. Якщо з інформаційною базою працює більше 5 користувачів, то рекомендується термінальне підключення до 1С – Windows Terminal Server входить до складу Windows 2000 Server. Якщо кількість користувачів у інформаційної бази 1С більше 12 або розмір бази більше 800 Мб, необхідно використовувати SQL версію "1С Підприємства 7.7".

4. Керуйте розміром інформаційної бази.

Чим менше в інформаційній базі даних, тим вона стійкіша і швидше працює. Для більшості правильно розроблених 1С змін існують процедури згортки (або закриття минулих облікових періодів), які дозволяють зменшити обсяг робочої інформаційної бази. З закритими обліковими періодами можна працювати з архівних копій бази.

5. Налаштуйте захист від дурня.

Найчастіше користувачі з недосвідченості або з необережності самі видаляють свої дані - або засобами тієї ж програми, в якій вони ці дані вводять (видаляються довідники, документи, і т.д.), або на системному рівні (наприклад, вирішивши самостійно "почистити" каталоги або видалити "непотрібні" файли на комп'ютері).

Боротися з цим можна лише адміністративними заходами: обмежувати або повністю закривати доступ окремих користувачів до довідників та документів, забороняти редагування та видалення документів у тих періодах, за якими зведено та здано баланс, тощо. Дуже корисно вести в програмі протокол роботи користувачів – хто і коли видаляв чи редагував документи та довідники.

Ця стаття підготовлена ​​з використанням матеріалів сайту "Школа 1С" http://www.1c-school.ru та ЗАТ "Гендальф" www.gendalf.ru