Гальма на файловій базі – як уникнути (з недавнього досвіду). Гальма на файловій базі - як уникнути (з недавнього досвіду) Не вдалося заблокувати таблицю config
Коштує 8.1 комплект на 5 користувачів.
Юзаєм типову бухгалтерію.
Працюють переважно через термінал, іноді і без нього.
Варіант бази даних – файловий
Помилки помічені у тих, хто у терміналі
якось так. Пірився в неті, Яндексі - взагалі якось неконкретно все.
Основні знайдені рекомендації:
1) Вивантажити/Завантажити базу - у сенсі нову зварити з конфігуратора
2) запустити \Prоgram Files\1cv81\bin\chdbfl.exe - перевірка фізичної цілісності бази
3) Провести Тестування та виправлення інформаційної бази
4) оновитись на останній реліз 8.1
Хто-небудь щось конкретніше знає?
13.5.2010, 10:05
Все, що треба, вам вже запропонували, спочатку це пробувати. Фізичних помилок на носії немає?
Конкретніше чи хтось скаже.
13.5.2010, 10:56
Так ця... якщо розглядати безвідносно 1С, а загалом, то тупо хтось із двох місць намагається заблокувати одну таблицю, перший встигає, а решту посилають. Дивись які операції/транзакції/обробки (або як це називається в 1С) виконуються в цей час. Цілком можливо, що справа не в платформі, а криво написаних конфігураціях або особливо роботи цих конфігурацій на ваших даних.
P.S. А файлові БД у розрахованому на багато користувачів режимі це збочення.
13.5.2010, 10:58
Хоча хрін його знає як у 1С-в зроблена БД, цілком можливо, що десь у БД ля запала і всілякі репайри допоможуть.
13.5.2010, 11:06
Так здається мені, восьмерина як платформа - вогкість та ще. Десь писали, що ПЕРІОДИЧНЕ тестування з виправленням доводиться робити
13.5.2010, 11:10
малоймовірно. Для вісімки новий сервак куплено аж із ліцензійною віндою
Суть у тому, що один блокує таблицю, решта чекає до тайм-ауту.
Чому не встигають, це велике питання. Фізичний носій подивитися може тупити. Системний журнал, MHDD. І всі ті дії, що написані у першому пості обов'язково.
P.S. Нове не означає, що 100% робоче.
13.5.2010, 11:38
Все що треба, вам уже запропонували, спочатку це пробувати
так то так, це до вечора треба чекати.
Була маленька надія щось нове почути
Не розказуйте чудес. Там бід вистачає, але то не вони.
де дива? Я не зрозумів, хтось зібрався стверджувати, що 8.1 є крута бездоганна платформа?
писали, що ПЕРІОДИЧНО тестування з виправленням доводиться робити
у нас схожий такий випадок і є.
Опитування користувачів поодинці (щоб не брехали дружно) показало, що ця ситуація зустрічається начебто ТІЛЬКИ у користувачів, що працюють у терміналі. А ті, хто ходять не через термінал, на якому
Windows Server 2003 R2 Standart 64 або не пам'ятають такої ситуації, або її просто не виникало у них.
Причому двоє особливо наглядових зазначили, що 1.5-2 місяці тому це явище спостерігалося НАМНОГО рідше
13.5.2010, 12:42
Born Killer, Антивір який-нитка стоїть на серваку? Якщо так, спробуй відключити або базу у виключення додати
13.5.2010, 13:14
Антивір якийсь нитка стоїть на серваку?
хз, треба глянути. Це ворожий сервак
хитрощі франчики одну з наших баз взяли на обслуговування, приперли свій сервер, і типу курирують нашу роботу
доступ до їхнього серваку надали, але у урізаному варіанті.
Подивлюсь.
немає там схоже на антивіруса...
13.5.2010, 13:23
Я не зрозумів, хтось зібрався стверджувати, що 8.1 є крута бездоганна платформа?
та ну нах. 7.7 то лажу місцями досі, а про 8-ку вчасно складати легенди про її глючність
Скільки база розміром та скільки користувачів?
Складайте. Наведіть конкретний приклад.
Скільки база розміром та скільки користувачів?
вночі зробив тестир та виправ. До цього 1cv8.1CD був 2Гб, зараз 1.5Гб став.
Користувачів 5 штук, як і власне ліцензія.
Щодо легенд про глючність, був один випадок. Ось якщо взяти 7.7 і просто через Тотал скопіювати 1 базу в інше місце – копія без проблем.
Одного разу спробував те саме зробити з вісімрічною базою, скопіював каталог бази в інше місце,
прописав, відкрив обидві бази одночасно, одна передбачалася для збочень.
У копії помітив на видалення кілька документів, переключився у вікно з реальною базою не повірив очам: ті самі документи помітилися на видалення і там
Ясен пень, у 1С на все є відповідь: робіть щоденну копію бази даних.
Та тільки це ху ша відповідь
МММарина
Born Killer,
Привіт друг...
Міф!
Ось так народжуються легенди...
Привіт друг...
Привіт подруга. Ось тебе занесло щось
А потім завмирали іконки на робочому столі
Міф!
Ось так народжуються легенди...
я це бачив. Мені не смішно потім було розрізняти проведені документи від непроведених після зняття позначки видалення всі вони стають непроведеними.
не пам'ятаю, яка платформа тоді стояла.
спробуйте також зробити. Може і у вас чо вийде
Ось так народжуються легенди...
скажу більше: коли я в копії вручну у парочки документів зняв позначку видалення,
у реальному основі сталося те саме. Мені тоді не було до того, щоб якось документувати цю сенсацію.
Тому я просто повернув усе, як було, і більше так не робив
усуваю зяючі дірки в пізнаннях комп'ютера.
правда, на мою думку, я безнадійна...
Саме ця тема взагалі не тобі, рідна (с)
а взагалі, все піддається осмисленню
заведи друга комп'ютерника, як варіант)))
У копії помітив на видалення кілька документів, переключився у вікно з реальною базою не повірив очам: ті самі документи помітилися на видалення і там shok.gif
Ось вже ніколи файлову базу не копіював 8-шну
Це була аж ніяк не сенсація.
Ви млинець можете не вірити, але це БУЛО.
Річ у тім, що з восьмою кілька років працював дуже щільно. Щойно їх не копіювали. Тож повірити не можу
Але можу припустити, що коли чол перевтомився - можливо багато. По собі знаю.
Не парься, файлову базу можна спокійно копіювати та піднімати у будь-якому іншому помсті. Жодних глюків бути не повинно.
14.5.2010, 10:52
14.5.2010, 11:28
Є припущення-по запарку прописав одну і ту ж базу 2 рази
8 пропонує замінити
14.5.2010, 11:31
її... 7.7 при спробі це зробити тупо мовчить і бази до списку не додає (просто ніяк не реагує)
8 пропонує замінити
Може просто мишею промазав і запустив одну і ту ж ... Чудес не буває
14.5.2010, 11:47
Може просто мишею промазав і запустив ту саму...
вдома спробую щось подібне змоделювати. Потім відпишусь.
Зазвичай перед будь-якою небезпечною дією я в 1С (7.7. або 8-ці) тисну на знак питання (там шлях до бази показаний).
Тут народ так дружно мою легенду на сміх підняв, що я засумнівався.
Хоча глюків у вісімці більше ніж у сімці.
О, ось стопудовий глюк, це бачив не лише я.
Взагалі знущалися з однієї 8-ї базою у клієнта, коли я ще у франчику працював.
Один день один чол, другий - другий, третього я пішов. Запитав у них – резеврну копію перед подвигами робили? У відповідь - іржуть, як коні, забили коротше, тільки вони базу брали на тій машині
14.5.2010, 12:35
- іржуть, як коні, забили коротше, тільки вони базу брали локально,
а мені випала нагода з мережі її ебошити. Резервну копію за прикладом попередніх товарів вирішив не робити,
молодий був і дурний – понтів багато.
Втім вніс зміни в конфу, зберігаю конфу, в момент збереження конфи якась аварія трапилася, і база впала, ввечері. Шок. З ранку пішли 3 фахівці, включаючи мене туди.
Аварія у тому, що з бази відірвало номер релізу, тобто. в конфігурації при натисканні запитань там було порожньо, і назва самої конфи була відсутня. і при ході в базу теж не видно ні хрону, інтерфейс в т.ч. злетів, до журналів документів було не зайти.
Вирішили проблему оновивши вбиту базу щодо свіжим файлом конфігурації, все вийшло.
Все відродилося.
Це є приклад реальної легенди. 3 особи не повинні глючити одночасно
14.5.2010, 13:53
в момент збереження конфи якась аварія сталася, і база впала
Ну, якщо це був глюк заліза, тоді нічого дивного.
А от якби ти знайшов баг, який стабільно з'являється після виконання певних дій, тоді інша розмова.
14.5.2010, 14:39
Ну, якщо це був глюк заліза, тоді нічого дивного
хз, що було. залізо, сітка або платформа – зараз уже не так важливо.
Мені здається, софтина не повинна так феєрично поводитися
Це теж саме, що випустити Вісту, і визнати, що це гівно. Як швидко вони з 8.0 на 8.1 перескочили
П.С. сенс слова баг мені зрозумілий, дякую за турботу)))
14.5.2010, 19:37
Скажімо, якщо при накочуванні сервіс-паків або чогось важливого на ту ж Вісту відбудеться подібний "глюк", то цілком імовірно, що система потім, якщо й завантажиться, працюватиме вкрай нестабільно.
Або, скажімо, в останній момент прийняття інсуліну відбудеться землетрус, то діабетик може дати кінці, т.к. шприц при трясіння закотився під диван.
14.5.2010, 22:32
Born Killer, Антивир якийсь нитка стоїть на серваку? Якщо так, спробуй відключити або базу у виключення додати
Як антивірус може вплинути на блокування таблиці? база 8.х – це один файл.
У копії помітив на видалення кілька документів, переключився у вікно з реальною базою не повірив очам: ті самі документи помітилися на видалення і там shok.gif
Взагалі ця погана бадилля мені не сподобалася, з тих пір копію бази роблю тільки через Вивантажити/Завантажити.
Як вам пане, така сумна легенда?
А якби я захопився і серйозніші речі накоїв у копії (наприклад видалив би помічені на видалення документи), і якимось незрозумілим чином, ті ж дії провели в основному базі?
Ні, цього не може бути, чудес не буває. Ймовірно ти увійшов в одну й ту саму базу ... У 8 без проблем можна увійти в базу 2 рази під одним ім'ям.
періодично полізли косяки під час проведення/запису документів з помилкою виду
"Конфлікт блокування при транзакції: Не вдалося заблокувати таблицю "_DOCUMENT158"
Так насамперед слід визначити якому документу метаданих відповідає таблиця "_DOCUMENT158". Для цього є метод глобального контексту "Отримати Структуру Зберігання Бази даних". Так ти зрозумієш хоча б точно який документ "глючить".
Потім потрібно зрозуміти, чи не змінював хтось у ньому модуль проведення і настукати по голові, якщо змінювали через одне місце. Найімовірніше явно записується набори записів регістрів через метод Записати замість того, щоб надати платформі це зробити коректно. І наплутана їх послідовність.
А дідлок не виникає?
А взагалі 5 людей не варто тримати у файловому режимі. Субд можна взяти безкоштовну, докупити лише ключ для сервера кластера та все. Чи це конторі дорого?
Я ось не пам'ятаю, технологічний журнал можна знімати у файловому режимі чи ні.
14.5.2010, 22:53
=========================================================
http://odines.ru/thread1386.html - це твоя гілка?
Тобто транзакція не проходить навіть коли працює один користувач? Тоді можливо проблема не в кривому коді при записі рухів. Тому що в режимі одного користувача блокувань бути не може. Адже запис послідовно проводиться.
Тоді схоже проблема саме в порушеннях у структурі самої бази.
Краще спочатку виконати Тестування та виправлення бази з увімкненим прапором "Реструктуризація таблиць інформаційної бази".
Вивантаження в dt з подальшим завантаженням теж має сенс.
chdbfl.exe у цьому випадку навряд чи допоможе... хоча звичайно пробувати варто, якщо решта не допоможе.
Ги - струму зараз подивився на дату постів у гілці http://odines.ru/thread1386.html Та й розробка типових у новому керованому режимі не за горами.
А вже різниця між 8.2 і 8.1 набагато більша ніж між 8.1 і 7.7 особливо для розробників, мізки доводиться капітально перебудовувати для розробки під "керований" режим роботи
Симптоми пацієнта та анамнез:
Робота декількох користувачів по мережі з одним і тим самим файлом (базою даних) включає механізм блокування мережі. Це змушує систему витрачати дорогоцінний час виявлення відкритих сесійзаписи, і відповідно вирішення конфліктів.
Основні ознаки роботи блокувань:
- швидка робота користувача з базою по мережі в монопольному режимі та вкрай повільна - при одночасної роботі кількох користувачів
- швидка робота користувача з локальною базою на сервері та повільна - по мережі
- звернення до файловій системітрохи менше 10 мбайт/сек
Отже, мені дісталося завдання - зробити так, щоб в 1С могли одночасно працювати цілих три користувача! Смішно, чи не так?
Всі жарти я забув, коли побачив, з чим належить мати справу: "сервер" в особі звичайного офісного комп'ютерата два ноутбуки.
Щастя було б неповним, якби не чудові Операційні системи- на комп'ютері та на одному ноутбук Windows 7, на іншому – Windows 8.
При спробі одночасно провести документи на ноутбуках один тупив близько хвилини, а другий вилетів із 1С із текстом помилки "не вдалося заблокувати таблицю...".
Запуск 1С на ноутбуці - це окреме шоу, яке тривало порядку 3 хвилини!
На багатьох ресурсах стикався із порадою перейти на роботу в термінальному доступі. На жаль, Windows 7 не дозволяє штатними засобамиперетворитися на сервер терміналів - максимум одне активне підключення. При цьому решта сеансів не припиняється, можна перепідключитися під іншим користувачем - "викинувши" при цьому попереднього користувача, але не завершивши його сеанс. Тому слід перенести 1С на серверну ОС, де таких обмежень немає. Клієнт на свій страх і ризик вирішив проблему натомість за допомогою сторонньої утиліти Windows7_SP1_RDPhack.
Але на цьому пригоди не скінчилися. Навіть у термінальному підключенні залишилися значні гальма. Знову мене виручили всемогутні пошукові системи. Нижче наведено поради щодо прискорення файлової 1С, яким я пішов:
1. Вимкнутивикористання протоколу мережі IPv6, налаштувати адресацію на "старому" IPv4
2. Додати процеси 1С у виключення брандмауера Windows, а також у виключення антивірусу, або відключити їх зовсім (більш ризиковано, але простий тест показав збільшення швидкостіперепроведення документів при відключеному антивірусі Avast в рази!)
3. Запустити індексацію повнотекстового пошуку в 1С або вимкнути його зовсім
4. Запустити Тестування та виправлення бази, перевірку утилітою ChDbfl
5. Запустити в конфігурації пункт Перевірка конфігурації (якщо конфігурація не є типовою, це може бути корисним). За результатами перевірки конфігурації вона чарівним чином зменшилася в розмірах майже на третину. Що вже і як до мене оновлювали програмісти, що приходять - особливо не вникав, але факт очевидний.
6. Вимкнути непотрібні функціональні опції.
7. Налаштувати права користувачам. (Цей і попередній поради здалися дурістю, доки я не поспостерігав за відмальовкою керованих формпід час відкриття списку документів. Чим менше зайвого в керованому інтерфейсі - тим, як правило, швидше він працює)
8. Запустити перерахунок підсумків та відновлення послідовності (значний приріст може бути лише у випадку, якщо довгий часпідсумки не відновлювалися)
9. Вказати "Швидкість з'єднання - низька" в налаштуваннях списку баз (це особливого результату не дало, хіба що відключилися картинки підсистем:))
Після виконання всіх цих кроків файлова база 1С запрацювала набагато швидше. Запускатись стала максимум секунд за 10, а швидкість перепроведення документів збільшилася в середньому в 12 разів.
Можливо, ця невелика стаття стане у нагоді і вам, якщо раптом знадобиться прискорити файлову базу 1С.
PS: А запустити файлову 1С, використовуючи мережевий доступдо загальної папки - все ж таки нереально, т.к. даші найшвидший твердотільний диск, оперативна пам'ятьі процесор уткнуться в мережеві блокування, і робота більше одного користувача буде неможливою. Йдеться безпосередньо про зміни УТ 11.1. Самописні невеликі конфігураціїЦілком можуть працювати дуже швидко навіть у файловому варіанті.
Доповнення із коментарівдо публікації:
Дефрагментація дисказ файловою базою
Згорткабази (може бути корисною, якщо база великого обсягу, наприклад, кілька років). У клієнта база була досить молода, тому пакунок був недоцільний.
Модернізація апаратної частини - швидший вінчестер, новий свитч, процесор і т.д.
Встановити на веб-сервер, доступ за допомогою тонкого клієнта. Тут думки розділилися. Хтось каже, у рази швидше, хтось – що прискорення не відзначено.
У розрахованих на багато користувачів системах важливу роль відіграє правильна організація структури і налаштування блокувань. Якщо її немає, користувачам доведеться часто стикатися з помилками, спричиненими конкуренцією за певні ресурси системи. Але є проблема конфлікту блокувань, знайома багатьом користувачам. Чому виникає конфлікт блокувань 1С та як його усунути?
Конфлікт блокувань в 1С 8.3 та його значення
Для більшості користувачів повідомлення про конфлікт блокувань 1С означає лише помилку, що заважає виконувати свою роботу. Вони хочуть якнайшвидше позбутися цієї проблеми і беруть в облогу IT-відділ скаргами на те, що «1С не працює».
Але для системних адміністраторівта розробників таке повідомлення говорить про можливу наявність проблем у структурі конфігурації. Перед тим, як намагатися догодити користувачам та прибрати блокування, необхідно проаналізувати ситуацію та зрозуміти причину виникнення повідомлення про помилку.
Причини виникнення помилок блокування в 1С
Показові тести навантаження демонструють, що сервер 1С витримує паралельну роботу більш ніж п'яти тисяч користувачів. Але ідеальні умови подібних експериментів недосяжні у повсякденних умовах великих та середніх компаній. Щоб досягти аналогічної швидкодії та безпомилковості, конфігурація має бути ідеально розроблена та заточена під конкретні бізнес-процеси підприємства.
Якщо не брати ідеальні варіанти, то конфлікти блокувань 1С трапляються з наступних причин:
Одночасна робота користувачів із великим обсягом даних.Ця причина продиктована внутрішніми механізмами 1С. Вони передбачають заборону зміни даних, залучених до транзакції, запущеної від імені іншого користувача;
Помилки та недоліки у конфігурації.У структурі типових рішень від компанії «1С» враховано рекомендації щодо максимізації продуктивності. Але сторонні розробники не завжди дотримуються високих стандартів, і в їхньому коді часто можна зустріти такі недоліки:
- неоптимальні запити;
- Запит залишків на початку дій;
- Нерозуміння призначення об'єктів конфігурації та його неправильне застосування;
- Надмірність закладених у системі або додатково розроблених блокувань.
Як виправити конфлікт блокувань у 1С 8.3
Системне повідомлення «конфлікт блокування при виконанні транзакції 1С 8.3» не характеризує конфігурацію як неправильно спроектовану. Але якщо подібні сигнали ігнорувати, існує ймовірність у найвідповідальніший момент, наприклад, при здачі квартальної чи річної звітності отримати великі проблеми. У найкращому разі – гальмуючу систему та незадоволених користувачів. У гіршому – неправильні дані на виході, що може спричинити штрафні санкції від контролюючих органів.
Вирішенням проблеми конфлікту блокувань в 1С 8.3 може стати переведення конфігурації на керований (ручний) режим керування блокуванням. Реалізований у версії 8.1 механізм у руках грамотних фахівців вирішує проблему конфлікту блокувань при транзакції в 1С.
Але варто мати на увазі, що ця дія зменшить рівень захисту даних від зміни в процесі читання їх іншими користувачами. Тому, якщо ви не готові самостійно контролювати всі блокування в системі, не поспішайте змінювати конфігураційні установки.
Швидке вирішення конфлікту блокувань 1С
У роботі адміністратора або розробника може статися ситуація, коли немає часу на перевірку помилки та пошук причин проблеми. Наприклад, необхідно подати звіт або подати дані до певного часу, а помилки блокувань 1С перешкоджають цьому.
Для швидкого вирішення проблеми існують два шляхи:
- Знайти та завершити сеанс, який заблокував необхідні дані. У невеликих компаніях, де кількість користувачів 1С не перевищує кількох десятків людей, це оптимальний варіантрішення;
- Якщо ви контролюєте систему, де працюють сотні співробітників, пошук потрібного сеансу без спеціалізованого програмного забезпеченняможе затягнутися надовго. У цьому випадку набагато ефективніше перезавантажити сервер.
Ці рішення радикальні та спрямовані лише на швидке рішенняпроблеми та звільнення даних для термінового складання звітів. Викоренити її можна лише розібравшись у причині, через яку виник конфлікт блокувань при виконанні транзакції 1С. Після таких дій необхідно знайти вразливі місця у системі, оптимізувати конфігурацію чи роботу працівників. Використовувати подібні заходи на постійній основі за регулярних конфліктів блокувань на транзакціях не рекомендується.
Нерідко під час роботи в 1С виникає помилка «Конфлікт блокувань під час виконання транзакцій: Перевищено максимальний час очікування надання блокування». Суть її полягає в тому, що кілька сеансів намагаються одночасно виконати схожі дії, торкаючись одного і того ж ресурсу. Сьогодні ми розберемося як виправити цю помилку
Велика кількість виконуваних операцій
Насамперед при пошуку причин слід уточнити, скільки одночасно користувачів, що працюють одночасно, знаходиться в тій інформаційній базі, в якій видається подібна помилка. Як ми знаємо, максимальна їх кількість може бути досить великою. Це і тисяча і п'ять тисяч.
Механізм блокувань та транзакцій описаний у посібнику розробника. Їх використовують при зверненні кількох сеансів до одних і тих самих даних одночасно. Логічно, що ті самі дані не можуть змінюватися різними користувачамив той самий момент.
Також слід перевірити, чи не запущено у когось із користувачів обробки масової зміни даних. Це може бути як закриття місяця тощо. У разі після закінчення роботи обробки помилка пропаде як така.
Регламентні завдання
Не рідкісні випадки, коли причина помилки криється в , що обробляє велику кількість даних. Рекомендується подібні речі робити вночі. Вкажіть розклад виконання таких регламентних завдань у позаробочий час.
Таким чином, і користувачі працюватимуть у стабільній системі, і самі регламентні завданнябудуть завершуватися успішно, оскільки знизиться ймовірність виникнення конфліктів з сеансами користувача.
«Завислі сеанси»
Проблема "завислих сеансів" користувачів знайома практично кожному, хто стикався з обслуговуванням 1С. Користувач міг уже давно вийти з програми, або закрити будь-який документ, але його сеанс, як і раніше, залишається в системі. Проблема найчастіше поодинока і досить завершити подібний сеанс через консоль адміністратора. Такі проблеми можуть виникнути і з фоновими завданнями.
За численними коментарями на просторах інтернету подібні ситуації найчастіше трапляються під час використання мережевих ключів захисту. Якщо ситуація із «зависаючими сеансами» повторюється систематично, це причина провести ретельну перевірку та обслуговування системи та серверів (якщо база клієнт-серверна).
Помилки під час написання конфігурації
Усі типові конфігурації розроблені кваліфікованими фахівцями та експертами. Кожна система ретельно тестується та оптимізується для більш швидкої та коректної роботи у ній.
У зв'язку з цим причина помилки може бути у неоптимальному коді, написаному стороннім розробником. Це може бути «важкий» запит, який блокуватиме дані на тривалий проміжок часу. Так само часті випадки побудови алгоритмів з низькою продуктивністю та порушенням логіки.
Велика ймовірність, що конфлікт блокування виник саме через помилки розробника, якщо він виник після оновлення програми. Для перевірки можна просто «відкотити» доопрацювання, або зробити рефакторинг коду.
Як часто доводиться бачити це повідомлення? Думаю, кожен хто має тривалий досвід роботи з 1С, хоч раз і стикався з такою помилкою. Через що програма видає таку ось помилку "Конфлікт блокувань при виконанні транзакції: Не вдалося заблокувати таблицю"?
Ну найчастіше це відбувається через те, що хтось із користувачів вже проводить якусь операцію, яка заблокувала цю таблицю. Щоб вирішити цю проблему, всім користувачам достатньо вийти з програми. Але буває так, що користувач вийшов із програми, а процес програми з пам'яті не вивантажився. Не панікуйте! Якщо всі користувачі вийшли з програми, а повідомлення все одно виходить, потрібно відкрити меню Сервіс -> Активні користувачі.
І подивитися, хто крім вас у Наразіпрацює із програмою. Якщо всі користувачі вийшли, а ви все ж таки бачите, що крім вас є ще хтось, не лякайтеся. Так буває. Завис процес. Перезавантажте комп'ютер користувача, який знаходиться в активних.
Але іноді це навіть не вирішує проблему. Буває, що в момент виконання транзакції моргає світло, або, наприклад жорсткий дискна останньому подиху. І що теж ймовірно, хтось вийняв шнур мережевого концентратора і включив на його місце чайник, а ви в цей момент проводили розрахунок амортизації. Так ось у такі моменти база може зашкодити або дані можуть бути записані з помилкою.
В даному випадку і майже завжди, якщо наведені вище рецепти не допомогли, допомагає утиліта chdbfl.exe. Перебувати вона в папці з виконуваним файлом 1С. Шлях до файлу буде приблизно такий "C:\Program Files\1Cv82\номер_версії_платформи\bin\chdbfl.exe". Зверніть увагу, що дана утиліта від однієї версії платформи, може не підійти до іншої.
Тому потрібно відкрити папку, саме з номером поточної платформи, на якій ви працюєте.
Як подивитися номер платформи? Дуже просто. Заходимо в меню Сервіс -> Про програму. І далі на зображенні показано, де дивитися номер платформи.
Ставимо галочку "виправляти виявлені помилки". І натискаємо кнопку виконати. Ця утилітавиправляє 90% всіх помилок, що відбуваються. Настійно рекомендую перед застосуванням даної утиліти зробити резервну копіюбази даних, а якщо помилка відбувається саме в момент вивантаження, то скопіюйте повністю папку з інформаційною базоюданих.