1с ошибка разделенного доступа к информационной базе
Обновлено: 06.07.2024
Любая программа, установленная на компьютер, может время от времени работать неправильно. Периодические сбои, которые приводят к невозможности использования ПО, называются ошибки. Чтобы суметь диагностировать и устранять ошибки в 1С, пользователь должен хотя бы немного разбираться в особенностях работы программ. Наличие минимальных знаний позволяет решать проблемы самостоятельно.
Прежде чем рассматривать основные разновидности ошибок, стоит заметить, что они отличаются между собой по происхождению. Приложение может привести к физическому или логическому сбою. В результате 1С просто не запускается или начинает работать в режиме «Конфигуратор». Пользовательский режим бывает недоступен или, при использовании определенных команд, будет появляться сбой.
Чтобы научиться быстро исправлять ошибки в 1С необходимо изначально их проанализировать. Часто во всплывающем окне написана суть некорректного поведения, что помогает решить проблему.
Причины появления ошибки в 1С
Разберем основные моменты, связанные с частым появлением сбоев при работе с базой данных. Они возникают в разных ситуациях, и определить их истинную причину не всегда возможно.
Одна из самых частых причин нарушение работы связанна с компьютером, на который установлена база данных 1С. Рабочая область может автоматически закрываться из-за нехватки оперативной памяти на сервере. Все возникающие неисправности должны быстро устраняться. В противном случае есть вероятность потери данных.
Часто возникающие ошибки 1С
Все имеющиеся сбои выводят на экран разные уведомления. Одинакового текста не бывает. Чтобы проще ориентироваться, разделим существующие ошибки 1С на следующие пункты:
- Недостаточно памяти.
- Ошибка доступа.
- Ошибка формата потока.
- Ошибка СУБД: Файл базы данных поврежден.
- Неправильное отображение блоков формы.
- Внутренняя ошибка компоненты dbeng.
- Dump при запуске.
- Неверный формат хранилища.
- Ничего не работает.
Для того, чтобы научиться исправлять возникающие ошибки, рассмотрим каждый пункт по отдельности.
Недостаточно памяти
Подобный сбой проявляется только в том случае, если на выполнение операций с программой выделено мало оперативной памяти. Приложение не может обрабатывать большие объемы информации, поэтому выдает «Недостаточно памяти 1С». Это случается при формировании отчета, обработки «тяжелого» файла, обновлении конфигурации и т.д. Причина – мощности компьютера недостаточно.
Пользователь может самостоятельно решить проблему с памятью. По умолчанию операционная система выделят фиксированное значение гигабайт на обслуживание приложения: 32 bit ОС – 2 Гб, 64 bit – 4 Гб.
Увеличить размер выделенной памяти можно вручную. Для этого запускается адресная строка (Пуск – Выполнить, вводиться фраза cmd). После нажатия «Ентер» достаточно ввести фразу bcdedit /set increaseuserva 4096 и подтвердить действие (клавиша «Enter»). Цифра 4096 – новый выделяемый объем «оперативки». Выполняется перезагрузка системы. Проблема должна быть устранена.
Ошибка доступа
Она возникает, если учетная запись не имеет достаточно прав. Проявляется при выполнении определенного действия, которое доступно только ограниченному кругу пользователей. Для исправления ситуации достаточно изменить роль выбранного профиля в конфигураторе (вкладка «Администрирование – Пользователи»). В некоторых случаях это увеличивает безопасность базы данных, если необходимо защитить файлы от изменения сторонними людьми.
Ошибка формата потока
Когда пользователь только запускает программу, на экране может появиться окно сбоя. Оно предлагает завершить работу или перезапустить. Причиной выступает некорректное завершение работы приложения.
Устранение подобной ошибки 1С выполняется простой чисткой кэша. Для этого необходимо перейти в папку, где хранятся временные файлы. В Windows 7 и выше она находится по адресу C:\Users\Username\AppData\Local\1C или C:\Users\Username\AppData\Roaming\1C. Для Windows ХР другой путь – Local Settings\Application Data\1C\. Все файлы, начинающиеся на 1cv8, кроме «1Cv8.1CD» полностью удаляются.
Если «Ошибка формата потока» возникает в процессе работы, то нужно провести тестирование (Администрирование – Тестирование и исправление), выбрать первые 2 галочки и запустить процесс.
Ошибка СУБД: Файл базы данных поврежден
Если всплывает информационное окно с подобной надписью, неисправность базы данных решается тестированием файла и всей информационной базы. Такое мероприятие может проводиться 2 способами:
- Запуск утилиты chdbfl.exe. Эта программа предназначена для того, чтобы проверять целостность базы данных при совместном ее использовании с информационной базой. Данный метод хорош тем, что дает возможность решать сбои даже в тех ситуациях, когда конфигуратор запустить невозможно. Сначала выполняется резервное копирование информации. В папке, где установлен 1С (директория bin) находится файл chdbfl.exe. Он запускается, в окне прописывает путь к файлу базы данных и ставится галочка, чтобы провести исправление ошибок. Нажимается кнопка «Выполнить». После завершения процесса все должно заработать. Если нет – используется конфигуратор.
- Через конфигуратор. Нужное окно вызывается после нажатия «Администрирование – Тестирование и исправление». На экране появляется форма, где выставляются галочки на следующе строчки: «Реиндексация таблиц…», «Проверка логической целостности…», «Проверка ссылочной…», «Реструктуризация таблиц…», «Тестирование и исправление» и 2 раза «Создать объекты». Нажимается кнопка «Выполнить». После завершения процедуры сбой устраняется.
Неправильное отображение блоков формы
Такая неисправность возникает от разных факторов. Чтобы привести программу к нормальной работоспособности, пользователю необходимо последовательно выполнить несколько команд. После проведения каждой проверяется устранение сбоя:
Если приведенные методы не помогают, рационально будет провести обновление платформы.
Внутренняя ошибка компоненты dbeng
Dump при запуске
Возвращение 1С в рабочее состояние проводится простым обновлением MS Visual Studio (Visual C++) и дополнительными манипуляциями. Чтобы отследить конкретный файл, в котором возникает ошибка, открывается «Просмотр событий». Для этого пользователь переходит в «Панель управления – Система и безопасность – Администрирование». С левой стороны раскрывается «Журнал Windows – Приложение».
На экране появляется список ошибок и точное расположение поврежденного файла. После установки новой версии MS Visual Studio (Visual C++) с папки System32 копируется одноименный файл dll и вставляется в папку платформы 1С. Проблема решилась.
Неверный формат хранилища
Ничего не работает
Если программа перестала нормально работать без видимых причин, значит пользователю придется самостоятельно искать неисправность. Для восстановления работоспособности базы данных проводятся следующие мероприятия:
- чистится кэш;
- открывается файл chdbfl.exe из папки установки приложения и выполняется исправление;
- выполняется запуск «Конфигуратора» для тестирования и исправления сбоев;
- обновление «1С».
Если это не критичная ошибка, она должна исправляться при установке актуальной версии программного комплекса. В остальных ситуациях необходимо пользоваться помощью профессиональных мастеров, которые отлично понимают принцип подобных продуктов.
Делал и рестарт сервера и перезапуск рабочего процесса, отключил фоновые задания. Ничего не помогает. Причем, в одной базе проходит стабильно, в другой не проходит и тоже стабильно.
Далее. Снял с поддержки. Не помогло.
Далее. Тестирование с исправлением "Проверка логической целостности" не помогло.
Аналогичная ситуация (и сервер 2005 и ругается так же и в конфигураторе вижу только свою сессию, правда на сервере 1С я вижу 2 сессии, но обе с моего компа Конфигуратор и еще какая-то, то ли сессия, то ли подключение . что-то подобное пишет). Платформа у меня 8.2.13.199 (последний релиз платформы так же не решил проблему, конфигурация УПП 1.3.12.1. Пробовал и с сервера заходить (не через локальную машину и не в терминале, а наживую с серверной машины, на которой стоят и сервер 1С и сыкуль. Результат тот же самый. Самое интересное, что ПЕРЕД тем как снимешь базу с полной техподдержки, всё выгружается и работает. А как только снял с полной техподдержки и добавил 1 реквизит типа булево в один из справочников . всё, финита ля камедия. Кто чем решал проблему или какие есть мысли? :cry: уже и на 2000 сыкуль пробовал загрузить (пишет мало памяти (8 гигов на сервере, этой привереде мало! При этом специально ребутал сервер, что бы не был ничем иным занят) "как только снял с полной техподдержки и добавил 1 реквизит типа булево в один из справочников . всё"
интересное наблюдение у меня - нет. могу припомнить, что наступал на сабж, по просто тупо рестартовал сервер, не вдаваясь В том-то и дело, что все задания я в консоли сервера отключал . да и вообще ставлю изначально на все базы запрет на рег задания. Я проблему решил.
Решилась она у меня путем снятия ВООБЩЕ с тех поддержки! Т.е. я отключил тех поддержку полностью! И после этого через сравнение конфигурации с файлом у меня всё замечательно обновляется! И выгрузка влёт начала проходить! Как иначе решить проблему . ну коли кто знает, отзовитесь! Самому интереснее всех! :-) (12) AganinEvgeniy,
У нас та же проблема. Тоже решаем рестартом сервера. Но это не вариант.
У нас конфа очень измененная, поэтому вариант снять с поддержки не рассматривается, она и так снята и ошибка вылетает, но замучились уже с этим ( хочется таки разобраться и решить все это. И снятие с поддержки не вариант, т.к. потом обновлять то тоже через прыжки с кувырком, а не стандартно. (16) Снятие с поддержки не вариант, согласен. Но я другого не нашел. Поэтому такие потуги "чешем левое ухо правой лапой" и вытворял. Так как базу нужно было обновить срочно, а она вылетала. Был и другой вариант, выгрузить базу в файловый вариант и на нем работать. Но меня оно не прельщает. И я так думаю, что возможен ещё один вариант, создать свою поставку базы на основе этой и её обновлять руками и держать в файловом варианте, а уже рабочую базу обновлять со своих файлов поставки . но это не меньшее изврапченство. Поэтому я и оставил у себя вариант с полным снятием с техподдержки и накатыванием обновления ручками через сравнение и объединение с конфигурацией их файла. (17) AganinEvgeniy,
Ясно. Спасибо Вам и за этот вариант, а то вообще копировали только средствами скуля, ни конфу не могли выгрузить ни базу ( так что хорошо когда есть хоть какие-то варианты борьбы, хуже когда вообще ничего нет ))) (18) Не за что. Похоже придется забыть о типовом обновлении. Я во всяком случае до сих пор не нашел ничего интереснее и приятнее. Так и сижу на 3-х базах для ведения в одной. ))) А пробовали опять на поддержку вернуть и что проверить будет ли она опять писать то же самое?
Я хочу сделать. Эксперименту ради :) (20) Честно говоря не делал. Если получится что-то путное . не сочтите за труд, известить. (21) AganinEvgeniy,
Хорошо. Обязательно отпишусь. Вы тоже пишите об экпериментах на эту тему.
У меня платформа 13я (22) У меня сейчас последняя версия платформы. нужно будет попробовать поставить на поддержку. Я-то с этим боролся, когда у меня стояла ещё 12-я версия. Как вариант, можно убить все ненужные сеансы, кроме своего из консоли серверов (26) И не может помочь, так как на сервере 1С при подключении к базе данных появляется сразу две сессии (во всяком случае у меня было именно так . точно уже не помню какие именно, но не обычные, которые появляются, когда я включаю на своей локалке конфигуратор и вхожу через сервер 1С:Предприятия: Конфигуратор и Сервер.) и при попытке срубить любую из них, клиент вылетал. (27) Э неее. Тут Вы не правы! Не будь у них ляпсусов, то и у сторонних разработчиков не было бы работы и жизнь всех пользователей была бы скучной и пресной! А так никогда не знаешь, что на этот раз отчибучат! И всем весело и у нас есть работа. )))) Таже проблема, возникла при обновлении БП на 8.2.31.07. Притом обновление до 8.2.30.08 прошло успешно. Перезагрузка не помогает. ТиИ тоже. Кто-нибудь решил без снятия с поддержки? Виной всему регламентные задачи :-) ставьте блокировку задач перезапускайте сервер 1С и выгружайте на здоровье.
Так же могут мешать подвисшие соединения, сеанса нет, а соединение осталось. (30) LSV79, Доброе утро. Не правда Ваша, батенька! Не виноватые рег задания. Чес слова! Я проверял! У меня в базе при создании они отключены были! И по поводу зависших сессий тоже не правда! У меня нет никого, кроме меня самого в конфигураторе. И эту же картину показывает и Агент сервера 1С:Предприятия, когда я в него заползаю. Кстати вот сейчас у меня стоит 15 релиз платформы и похожая ситуация у меня стала проявляться и с конфигурациями находящимися на полной техподдержке. Похоже, что в релизе 8.2.15 что-то не то творится . мне только перезагрузка сервера помогает, что бы можно было базу даже просто выгрузить! Блокировка регл заданий стоит изначально, перезагрузка сервера 1С, sql сервера тоже не помогает. Соединения конечно посмотрю, но кроме меня с базой никто не работает. Такая же шляпа была. Закрыл конфигуратор, в 1с сервере в свойствах базы воткнул галку "запретить выполнять регламентированные задания" (кажется так написано), остановил 1с сервер, запустил заново, и, о чудо - заработало! в 8.1 такой фигни не было. Чет глюк 1с сервера походу. Проблема решена снятием с поддержки и загрузкой cf 8.2.32.4 релиза. Так что - никакой конкретики так и не появилось? только танцы с бубном? Такая же ерунда, причем ругается сам на себя!
Ошибка разделенного доступа к информационной базе
Активны сеансы:
компьютер: TERMSRV, сеанс: 28, начат: 22.03.2012 в 15:05:40, приложение: Конфигуратор (37) PavluhaKUZ, ага, обновил платформу с сервером, бесполезно, как ругался, так и ругается. только после перезапуска сервера вроде соображает чего от него хотят. 1сники интересно чего-нить делают с этой проблемой?)) (38) Делают конечно! Они её усугубляют. )))) Во всяком случае такая петрушка на 12-14 релизах у меня была только на измененной конфигурации УПП и решилась, когда я полностью снял с техподдержки эту конфигурацию. А начиная с 15 релиза . маразм крепчал. (37) Да, такая же ситуация. При том даже на полностью типовых конфигурациях не снятых с полной тех поддержки. Но произошло это у меня только на 15 релизе платформы. И пока не исправилась ситуация. Я поступаю так: перед необходимостью выполнения каких-то работ просто перезагружаю службу сервера 1С, а если это не возможно, то утром делаю копии баз и на них уже выполняю всякие истязательства, а уже по факту выгоняю пользователей и работаю. Так что думаю нужно ждать 16 релиза платформы . как это не прискорбно да именно так. не было в списке активных пользователей никого. зато в скуле висел пользователь (43) даже если и так, то почему когда 1с сервер перезапускаю, все нормально выгружается? sql вообще не трогаю (44) в вашем варианте может другая причина была. Возможно фоновые задание были запущены.
у меня была другая причина получается (45) получается в любом случае гоморой)))))) и главное началось то все с 8.2 платформы. (46) у меня проблема с пользователем на скуле была когда были на 8.0. В 8.1 тоже такое встречалось, но причина была думаю в фоновых заданиях. потому что через минут 10 уже ошибки не было. В 8.2 пока не встречал.
Обновился до платформы 8.2.15.301. теперь вообще при открытом конфигураторе не пускает клиентов. Ошибка та же.
Ошибка разделенного доступа. перезапуск SQL и агента не помогает.
результат на сегодняшний день:
1.Вообще не выгружает базу.
2.Не делает обновление конфигурации.
3.При открытом конфигураторе не пускает пользователей.
При всех трех случаях ошибка одна и та же.
P.S. Все фоновые отключены. сессия планировщика сброшена через консоль. по отдельности сервисы перезапускал.
Да и еще не знаю относиться это данной проблеме или нет, но после обновления очень часто стал зависать Агент.
может потому что с системной учеткой. поменял на спец. учетку посмотрим.
спец учетку добавил в группу админов с полными правами. В SQL доступ к ней прописан.
Сейчас обхожусь выгрузкой через SQL, но ведь это не решение. бэкап SQL в 10 раз больше dt. (50) Так-то да, бэкап огромный просто)) У меня ночью сервак перезагружается и только уже после этого делается резервная копия. Все это делаю назначенными заданиями. А по другому никак)))) Сабж. Платформа 8.2.15. Блокировка регламентных заданий стояла. Вышел из конфигуратора. Снял блокировку и сразу же поставил снова - выгрузка получилась. Вставлю свои пять копеек. У меня 4 отдельных локальных сети. В 3-х сетях все работает без замечаний, а в 4-й аналогичная проблема с выгрузкой базы. Но не только с выгрузкой. Ну, выгрузки, ладно. Базы не сильно большие, пока можно и SQL-ный backup делать. Кроме этого, не проходят обновления РиБ при изменениях главного узла. При этом, совершенно не важно, находится главный узел в рассматриваемой локальной сети или в рассматриваемой локальной сети подчиненный узел. Конфигурации УПП, полностью снимать с поддержки не буду - геморрой при обновлениях себе наживу. Из множества фактов, собранных при наблюдении данной проблемы, я могу пока сделать только вывод о том, что является краеугольным камнем проблемы. А вывод такой: при любом обращении к конфигурации поставщика (!), даже на чтение, происходит сбой. Похоже, что в последних релизах УПП конфигурация выросла до критического размера и начинает сбоит сервер 1С. Решения проблемы у меня нет, те же перезагрузка сервера, SQL-ные backup-ы, попытки перегружать процессы, грешить на регламентные задания. Еще интересное наблюдение, что в проблемной локальной сети физический компьютер заметно слабее, чем в остальных: 32-х битный сервер 2003, 4Гб ОЗУ. По развитию событий. Жду когда админы переставят операционную систему на сервере и переставят сервер 1С предприятия в той же конфигурации, но, при этом, произойдет увеличение дискового пространства на диске, на котором сервер 1С предприятия хранит временные файлы. Надеюсь на решение проблемы. Используя обработку "Консоль заданий" отключите использование долгоиграющих заданий (особенно Слияние(обновление) индекса полнотекстового поиска. Проблема разделенного доступа отпадет. В консоле снимите у этой базы соединения которые выдает блокировку, помогает. И ничего не надо рестартовать и шаманить. Как вариант можно не рестарт сервера делать, а попытку detach базы, там покажет сколько подключений и далее нажать на кнопку clear и скуль отрубит все сеансы, соответственно исправит сабж. Как-то так. каждый вечер после полного обмена со всеми базами риб, появляется процесс фоновое задание. и выгрузить нереально базу, жду пока успокоится, занимает минут 10 этот процесс. так же при заполнении базы большим количеством данных(обработка т.д.) тоже этот процесс появляется. заметил sql при этом нормально загружен, как бы ре индексация идет.
Конфигурация УПП 1.3.26.1, Платформа 8.2.14.540. Конфа немного отредактированная, есть маленькие дописки. Обновление конфигурации до релиза 1.3.27.2 проводил сравнением и объединением. Все прошло на ура! обновилось все замечательно. Траблы начались на следующий день. При выводе на печать документа "доверенность" выдается ошибка
: Преобразование значения к типу Число не может быть выполнено
ОбластьМакета.Параметры.ФИОДоверенного = ДолжностьДоверенного + " " + ОбщегоНазначения.ФамилияИнициалыФизЛица(ФамилияИмяОтчествоДоверенного);
При этом если убрать физлицо в документе то все нормально. То же самое обновление делал в типовой, там все нормально работает.
На это все не закончилось. Решил все проверить и перед этим выгрузить Базу в файл ДТ. Тут то и выдалась эта ошибка про разделенный доступ. Ругается на мой же сеанс. Сервер перегрузил, 1с сервер тоже. Ничего не помогло.
В том то и дело, что документ "Доверенность" вообще не трогал. там все осталось как было. даже сравнение это показывает. Но глюк все таки наблюдается. причем несколько прошлогодних доверенностей печатаются нормально. а остальные выдают эту ошибку. такое ощущение просто что где то переклинивает))) (63) это значит ставить точки останова (F9) в конфигураторе, там где предположительно возникает ошибка. Когда появляется ошибка нажимай кнопку подробно, программа скажет в каком модуле и в какой строке произошла ошибка. Дальше по Shift+F9 смотришь переменные и ищешь ошибку
На ИТС часто даются описания кодов ошибок, но они не всегда исчерпывающие. В этой статье мы будем пытаться продолжать "исчерпывать" :)
При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:
Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005
Признаки проблемы: нельзя выгрузить в dt
Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь http://www.gilev.ru/1c/mssql/errsql.htm . Здесь же мы говорим именно о "неопознанной ошибке" :)
Сотрудники 1С рекомендуют решать проблему так:
3. Также с этой ситуацией пересекается следующая ситуация:
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
select top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что "Стандартные проверки" платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель "запрет на фоновые задания" в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском - вещь в себе - и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять - возможно проблема "уйдет".
2. Перезапустить сервер
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться "возврат" к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем "загрузить конфигурацию" (не объединение)
вот пример работоспособности этого приема
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу "config"
Читайте также: