Ошибка разделенного доступа к информационной базе при выгрузке скульной базы.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Dialog,
Делал и рестарт сервера и перезапуск рабочего процесса, отключил фоновые задания. Ничего не помогает. Причем, в одной базе проходит стабильно, в другой не проходит и тоже стабильно.
Далее. Снял с поддержки. Не помогло.
Далее. Тестирование с исправлением "Проверка логической целостности" не помогло.
Делал и рестарт сервера и перезапуск рабочего процесса, отключил фоновые задания. Ничего не помогает. Причем, в одной базе проходит стабильно, в другой не проходит и тоже стабильно.
Далее. Снял с поддержки. Не помогло.
Далее. Тестирование с исправлением "Проверка логической целостности" не помогло.
Собственно в продолжение темы.
Аналогичная ситуация (и сервер 2005 и ругается так же и в конфигураторе вижу только свою сессию, правда на сервере 1С я вижу 2 сессии, но обе с моего компа Конфигуратор и еще какая-то, то ли сессия, то ли подключение ... что-то подобное пишет). Платформа у меня 8.2.13.199 (последний релиз платформы так же не решил проблему, конфигурация УПП 1.3.12.1. Пробовал и с сервера заходить (не через локальную машину и не в терминале, а наживую с серверной машины, на которой стоят и сервер 1С и сыкуль. Результат тот же самый. Самое интересное, что ПЕРЕД тем как снимешь базу с полной техподдержки, всё выгружается и работает. А как только снял с полной техподдержки и добавил 1 реквизит типа булево в один из справочников ... всё, финита ля камедия. Кто чем решал проблему или какие есть мысли? :cry: уже и на 2000 сыкуль пробовал загрузить (пишет мало памяти (8 гигов на сервере, этой привереде мало! При этом специально ребутал сервер, что бы не был ничем иным занят)
Аналогичная ситуация (и сервер 2005 и ругается так же и в конфигураторе вижу только свою сессию, правда на сервере 1С я вижу 2 сессии, но обе с моего компа Конфигуратор и еще какая-то, то ли сессия, то ли подключение ... что-то подобное пишет). Платформа у меня 8.2.13.199 (последний релиз платформы так же не решил проблему, конфигурация УПП 1.3.12.1. Пробовал и с сервера заходить (не через локальную машину и не в терминале, а наживую с серверной машины, на которой стоят и сервер 1С и сыкуль. Результат тот же самый. Самое интересное, что ПЕРЕД тем как снимешь базу с полной техподдержки, всё выгружается и работает. А как только снял с полной техподдержки и добавил 1 реквизит типа булево в один из справочников ... всё, финита ля камедия. Кто чем решал проблему или какие есть мысли? :cry: уже и на 2000 сыкуль пробовал загрузить (пишет мало памяти (8 гигов на сервере, этой привереде мало! При этом специально ребутал сервер, что бы не был ничем иным занят)
Я проблему решил.
Решилась она у меня путем снятия ВООБЩЕ с тех поддержки! Т.е. я отключил тех поддержку полностью! И после этого через сравнение конфигурации с файлом у меня всё замечательно обновляется! И выгрузка влёт начала проходить! Как иначе решить проблему ... ну коли кто знает, отзовитесь! Самому интереснее всех! :-)
Решилась она у меня путем снятия ВООБЩЕ с тех поддержки! Т.е. я отключил тех поддержку полностью! И после этого через сравнение конфигурации с файлом у меня всё замечательно обновляется! И выгрузка влёт начала проходить! Как иначе решить проблему ... ну коли кто знает, отзовитесь! Самому интереснее всех! :-)
(12) AganinEvgeniy,
У нас та же проблема. Тоже решаем рестартом сервера. Но это не вариант.
У нас конфа очень измененная, поэтому вариант снять с поддержки не рассматривается, она и так снята и ошибка вылетает, но замучились уже с этим ( хочется таки разобраться и решить все это.
У нас та же проблема. Тоже решаем рестартом сервера. Но это не вариант.
У нас конфа очень измененная, поэтому вариант снять с поддержки не рассматривается, она и так снята и ошибка вылетает, но замучились уже с этим ( хочется таки разобраться и решить все это.
(16) Снятие с поддержки не вариант, согласен. Но я другого не нашел. Поэтому такие потуги "чешем левое ухо правой лапой" и вытворял. Так как базу нужно было обновить срочно, а она вылетала. Был и другой вариант, выгрузить базу в файловый вариант и на нем работать. Но меня оно не прельщает. И я так думаю, что возможен ещё один вариант, создать свою поставку базы на основе этой и её обновлять руками и держать в файловом варианте, а уже рабочую базу обновлять со своих файлов поставки ... но это не меньшее изврапченство. Поэтому я и оставил у себя вариант с полным снятием с техподдержки и накатыванием обновления ручками через сравнение и объединение с конфигурацией их файла.
(26) И не может помочь, так как на сервере 1С при подключении к базе данных появляется сразу две сессии (во всяком случае у меня было именно так ... точно уже не помню какие именно, но не обычные, которые появляются, когда я включаю на своей локалке конфигуратор и вхожу через сервер 1С:Предприятия: Конфигуратор и Сервер.) и при попытке срубить любую из них, клиент вылетал. (27) Э неее!!! Тут Вы не правы! Не будь у них ляпсусов, то и у сторонних разработчиков не было бы работы и жизнь всех пользователей была бы скучной и пресной! А так никогда не знаешь, что на этот раз отчибучат! И всем весело и у нас есть работа. ))))
(30) LSV79, Доброе утро. Не правда Ваша, батенька! Не виноватые рег задания!!! Чес слова! Я проверял! У меня в базе при создании они отключены были! И по поводу зависших сессий тоже не правда! У меня нет никого, кроме меня самого в конфигураторе. И эту же картину показывает и Агент сервера 1С:Предприятия, когда я в него заползаю. Кстати вот сейчас у меня стоит 15 релиз платформы и похожая ситуация у меня стала проявляться и с конфигурациями находящимися на полной техподдержке. Похоже, что в релизе 8.2.15 что-то не то творится ... мне только перезагрузка сервера помогает, что бы можно было базу даже просто выгрузить!
Такая же шляпа была. Закрыл конфигуратор, в 1с сервере в свойствах базы воткнул галку "запретить выполнять регламентированные задания" (кажется так написано), остановил 1с сервер, запустил заново, и, о чудо - заработало! в 8.1 такой фигни не было. Чет глюк 1с сервера походу.
(37) Да, такая же ситуация. При том даже на полностью типовых конфигурациях не снятых с полной тех поддержки. Но произошло это у меня только на 15 релизе платформы. И пока не исправилась ситуация. Я поступаю так: перед необходимостью выполнения каких-то работ просто перезагружаю службу сервера 1С, а если это не возможно, то утром делаю копии баз и на них уже выполняю всякие истязательства, а уже по факту выгоняю пользователей и работаю. Так что думаю нужно ждать 16 релиза платформы ... как это не прискорбно
Обновился до платформы 8.2.15.301. теперь вообще при открытом конфигураторе не пускает клиентов. Ошибка та же.
Ошибка разделенного доступа. перезапуск SQL и агента не помогает.
результат на сегодняшний день:
1.Вообще не выгружает базу.
2.Не делает обновление конфигурации.
3.При открытом конфигураторе не пускает пользователей.
При всех трех случаях ошибка одна и та же.
P.S. Все фоновые отключены. сессия планировщика сброшена через консоль. по отдельности сервисы перезапускал.
Да и еще не знаю относиться это данной проблеме или нет, но после обновления очень часто стал зависать Агент.
может потому что с системной учеткой. поменял на спец. учетку посмотрим.
Ошибка разделенного доступа. перезапуск SQL и агента не помогает.
результат на сегодняшний день:
1.Вообще не выгружает базу.
2.Не делает обновление конфигурации.
3.При открытом конфигураторе не пускает пользователей.
При всех трех случаях ошибка одна и та же.
P.S. Все фоновые отключены. сессия планировщика сброшена через консоль. по отдельности сервисы перезапускал.
Да и еще не знаю относиться это данной проблеме или нет, но после обновления очень часто стал зависать Агент.
может потому что с системной учеткой. поменял на спец. учетку посмотрим.
Поменял на спец учетку - проблема с зависанием ушла, а вот базу как не выгружало так и не выгружает.
спец учетку добавил в группу админов с полными правами. В SQL доступ к ней прописан.
Сейчас обхожусь выгрузкой через SQL, но ведь это не решение...бэкап SQL в 10 раз больше dt....
спец учетку добавил в группу админов с полными правами. В SQL доступ к ней прописан.
Сейчас обхожусь выгрузкой через SQL, но ведь это не решение...бэкап SQL в 10 раз больше dt....
Вставлю свои пять копеек. У меня 4 отдельных локальных сети. В 3-х сетях все работает без замечаний, а в 4-й аналогичная проблема с выгрузкой базы. Но не только с выгрузкой. Ну, выгрузки, ладно. Базы не сильно большие, пока можно и SQL-ный backup делать. Кроме этого, не проходят обновления РиБ при изменениях главного узла. При этом, совершенно не важно, находится главный узел в рассматриваемой локальной сети или в рассматриваемой локальной сети подчиненный узел. Конфигурации УПП, полностью снимать с поддержки не буду - геморрой при обновлениях себе наживу. Из множества фактов, собранных при наблюдении данной проблемы, я могу пока сделать только вывод о том, что является краеугольным камнем проблемы. А вывод такой: при любом обращении к конфигурации поставщика (!), даже на чтение, происходит сбой. Похоже, что в последних релизах УПП конфигурация выросла до критического размера и начинает сбоит сервер 1С. Решения проблемы у меня нет, те же перезагрузка сервера, SQL-ные backup-ы, попытки перегружать процессы, грешить на регламентные задания. Еще интересное наблюдение, что в проблемной локальной сети физический компьютер заметно слабее, чем в остальных: 32-х битный сервер 2003, 4Гб ОЗУ. По развитию событий. Жду когда админы переставят операционную систему на сервере и переставят сервер 1С предприятия в той же конфигурации, но, при этом, произойдет увеличение дискового пространства на диске, на котором сервер 1С предприятия хранит временные файлы. Надеюсь на решение проблемы.
каждый вечер после полного обмена со всеми базами риб, появляется процесс фоновое задание. и выгрузить нереально базу, жду пока успокоится, занимает минут 10 этот процесс. так же при заполнении базы большим количеством данных(обработка т.д.) тоже этот процесс появляется. заметил sql при этом нормально загружен, как бы ре индексация идет.
Конфигурация УПП 1.3.26.1, Платформа 8.2.14.540. Конфа немного отредактированная, есть маленькие дописки. Обновление конфигурации до релиза 1.3.27.2 проводил сравнением и объединением. Все прошло на ура! обновилось все замечательно. Траблы начались на следующий день. При выводе на печать документа "доверенность" выдается ошибка
{Документ.Доверенность.МодульОбъекта(62)}: Преобразование значения к типу Число не может быть выполнено
ОбластьМакета.Параметры.ФИОДоверенного = ДолжностьДоверенного + " " + ОбщегоНазначения.ФамилияИнициалыФизЛица(ФамилияИмяОтчествоДоверенного);
При этом если убрать физлицо в документе то все нормально. То же самое обновление делал в типовой, там все нормально работает.
На это все не закончилось. Решил все проверить и перед этим выгрузить Базу в файл ДТ. Тут то и выдалась эта ошибка про разделенный доступ. Ругается на мой же сеанс. Сервер перегрузил, 1с сервер тоже. Ничего не помогло.
{Документ.Доверенность.МодульОбъекта(62)}: Преобразование значения к типу Число не может быть выполнено
ОбластьМакета.Параметры.ФИОДоверенного = ДолжностьДоверенного + " " + ОбщегоНазначения.ФамилияИнициалыФизЛица(ФамилияИмяОтчествоДоверенного);
При этом если убрать физлицо в документе то все нормально. То же самое обновление делал в типовой, там все нормально работает.
На это все не закончилось. Решил все проверить и перед этим выгрузить Базу в файл ДТ. Тут то и выдалась эта ошибка про разделенный доступ. Ругается на мой же сеанс. Сервер перегрузил, 1с сервер тоже. Ничего не помогло.
(60) Zero_nv,
В том то и дело, что документ "Доверенность" вообще не трогал. там все осталось как было. даже сравнение это показывает. Но глюк все таки наблюдается. причем несколько прошлогодних доверенностей печатаются нормально. а остальные выдают эту ошибку. такое ощущение просто что где то переклинивает)))
В том то и дело, что документ "Доверенность" вообще не трогал. там все осталось как было. даже сравнение это показывает. Но глюк все таки наблюдается. причем несколько прошлогодних доверенностей печатаются нормально. а остальные выдают эту ошибку. такое ощущение просто что где то переклинивает)))
(63) это значит ставить точки останова (F9) в конфигураторе, там где предположительно возникает ошибка. Когда появляется ошибка нажимай кнопку подробно, программа скажет в каком модуле и в какой строке произошла ошибка. Дальше по Shift+F9 смотришь переменные и ищешь ошибку
На ИТС часто даются описания кодов ошибок, но они не всегда исчерпывающие. В этой статье мы будем пытаться продолжать "исчерпывать" :)
При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:
Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005
Признаки проблемы: нельзя выгрузить в dt
Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь . Здесь же мы говорим именно о "неопознанной ошибке" :)
Сотрудники 1С рекомендуют решать проблему так:
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду "Проверка конфигурации" с установленным флажком "Проверка логической целостности конфигурации". При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Дата публикации: 2008-11-13
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
select top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что "Стандартные проверки" платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С - это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
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"
DROP TABLE [dbo].[Config]
5) делаем "загрузить конфигурацию" (не объединение) из cf
после этого проверяем, проблема уходит.
При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:
Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005
Признаки проблемы: нельзя выгрузить в dt
Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь . Здесь же мы говорим именно о "неопознанной ошибке" :)
Сотрудники 1С рекомендуют решать проблему так:
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду "Проверка конфигурации" с установленным флажком "Проверка логической целостности конфигурации". При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Дата публикации: 2008-11-13
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
select top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что "Стандартные проверки" платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С - это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
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"
DROP TABLE [dbo].[Config]
5) делаем "загрузить конфигурацию" (не объединение) из cf
после этого проверяем, проблема уходит.
Спасибо всем за участие в данной проблеме. Сегодня проблему вроде решил. Не уверен что поступил правильно. Но опишу что сделал, может кому нибудь пригодится.
Была ошибка при выгрузке базы в файл ДТ, система ругалась на ошибку неразделенного доступа к базе, и ссылалась на мой же сеанс.
Перезагрузка Агента серверов 1С не дала никакого результата.
Перезагрузка Сервера также не возымело успеха.
Детач базы менеджером скуля тоже не дал результатов.
Далее чтобы не повредить рабочую базу, средствами скуля сделал копию базы. Попробовал выгрузить из копии. Результат тот же! Т.е. опять поругала про разделенный доступ к базе. Моральное состояние мое вообще было на грани инфаркта.
В итоге пошел на последний вариант. Полностью снял с поддержки конфигурацию. и ВУАЛЯ!!!!! База без проблем выгрузилась!!!
Кстати возможно все произошло изза устаревшей платформы 8.2.14.540.
Но переводить на новую пока не могу. Поэтому пришлось так извращаться.
Надеюсь кому нибудь будет полезна данная информация.
Была ошибка при выгрузке базы в файл ДТ, система ругалась на ошибку неразделенного доступа к базе, и ссылалась на мой же сеанс.
Перезагрузка Агента серверов 1С не дала никакого результата.
Перезагрузка Сервера также не возымело успеха.
Детач базы менеджером скуля тоже не дал результатов.
Далее чтобы не повредить рабочую базу, средствами скуля сделал копию базы. Попробовал выгрузить из копии. Результат тот же! Т.е. опять поругала про разделенный доступ к базе. Моральное состояние мое вообще было на грани инфаркта.
В итоге пошел на последний вариант. Полностью снял с поддержки конфигурацию. и ВУАЛЯ!!!!! База без проблем выгрузилась!!!
Кстати возможно все произошло изза устаревшей платформы 8.2.14.540.
Но переводить на новую пока не могу. Поэтому пришлось так извращаться.
Надеюсь кому нибудь будет полезна данная информация.
После обновления конфигурации Комплексная автоматизация на номер 1.1.23.3 перестала выгружаться база средствами конфигуратора.
Сервер Win2008 + SQL2008, всё 32-разрядное. SQL выгружал без проблем. На сервере 4 Гб оперативки. Проблема решилась прописывание параметров загрузки сервера boot.ini. В Win 2003 это параметры /3GB /PAE. В Win2008 в командной строке прописываем (bcdedit.exe /set increaseuserva 3072) - это /3GB и (bcdedit.exe /set pae forceenable). После всех манипуляций перезагружаем сервер и всё заработало. Выгружается и загружается средствами конфигуратора.
Сервер Win2008 + SQL2008, всё 32-разрядное. SQL выгружал без проблем. На сервере 4 Гб оперативки. Проблема решилась прописывание параметров загрузки сервера boot.ini. В Win 2003 это параметры /3GB /PAE. В Win2008 в командной строке прописываем (bcdedit.exe /set increaseuserva 3072) - это /3GB и (bcdedit.exe /set pae forceenable). После всех манипуляций перезагружаем сервер и всё заработало. Выгружается и загружается средствами конфигуратора.
(70) apbelg, все прописанно уже давно, мало того на сервере 8 гб оперативки, два Xeon`а по четыре ядра каждый, и как не выгружало так и не выгружает, перепробовал уже все рекомендованные способы. пришел к выводу что это ошибка платформы. будем ждать и молиться чтобы исправили. бекап SQL весит в 10 раз больше. как то так.
Уважаемый PavluhaKUZ, не претендую на оригинальность. Описал лишь свою проблему и то, что мне помогло реально. Уже две недели всё работает. Надеюсь, что и дальше будет все ОК. Может быть у Вас надо что-то другое делать...
(74) оперативной? рестарт сервера 1с поможет? еще момент,который меня очень интересует - в случае быстрой процедуры остановки, а затем запуска сервера 1с пользователи спокойно работают дальше (по-моему раньше, в любом случае, при остановке всех пользователей выбрасывало). так вот, есть ли польза от такого рестарта? раз пользователи продолжают работать, то видимо и занятая память не будет высвобождена.
(75) Ольга_tmp, пользователи не могут работать дальше. Значит Вы как то не так делаете рестарт. как только останавливаются рабочие процессы - пользователи отваливаются. могут не сразу а при обрашении к базе но отваливаются. Рестартовать надо сервис "Агент сервера 1С:Предприятие". есть еще вариант что по каким то причинам их у вас два.
(76) PavluhaKUZ, Ольга правду говорит. Если я перезапускаю службу "Агент сервера 1С:Предприятие", то пользователи не отрубаются, это похоже новая фишка платформы ... не знаю когда она точно появилась, но я заметил этот баг на 15 платформе. И кстати, сейчас у меня стоит последняя (8.2.16...что-то там) платформа и плюс к этому я добавил ещё 1 процесс в кластер 1С. И после этого, пока у меня всё замечтательно работает. Больше не ругается (точнее было один раз ругалась на мой сеанс, но вот на нехватку памяти перестало ругаться).
Похоже баг (или фича) осталась и в новых версиях т.к. столкнулся с аналогичной проблемой.
Началось с того что нужно было реквизит в Регистр бухгалтерии Хозрасчетный, так 1С послала меня так (делал не на Сервере 1С):
При попытке выгрузить не на Сервере 1С отказывалось с непомню дословно что то типа: администратор запретил (закрыл) соеденение.
А при попытке выгрузить именно на Сервере 1С при запуске выгрузки думает 1 мин. и Конфигуратор говорит о мешающем сеансе Конфигуратора за номером таким то. До старта его не было и это не мой сеанс. Этот сеанс хорошо видно в утилите "Администрирование серверов 1С" в базе в разделе блокировки. Откуда он создается непонятно. Баг с выгрузкой ушел после рестарта службы Сервера 1С.
Но проблема с добавлением реквизита осталась! Если кто знает - подскажите!
-----------------------------------------------------------------
Сервер 1С:
Железо: WinXP Prof SP3 32-x / Core Quad Q8300 2.5 GHz / 3,46 Gb
Софт:
Платформа 1С: 8.2.17.143
Конфигурация: Бухгалтерия предприятия, редакция 2.0 (2.0.40.8)
-----------------------------------------------------------------
SQL:
Железо: Win 7 Prof 64-x / Core i5-3470 3.2 GHz / 16 Gb
Софт: MS SQL 2005 (9.00.1399)
Началось с того что нужно было реквизит в Регистр бухгалтерии Хозрасчетный, так 1С послала меня так (делал не на Сервере 1С):
В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: The transaction log for database 'accnt' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=4, Severity=11, native=9002, line=1
SQLSrvr: SQLSTATE=42000, state=4, Severity=11, native=9002, line=1
по причине:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: The transaction log for database 'accnt' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=4, Severity=11, native=9002, line=1
SQLSrvr: SQLSTATE=42000, state=4, Severity=11, native=9002, line=1
При попытке выгрузить не на Сервере 1С отказывалось с непомню дословно что то типа: администратор запретил (закрыл) соеденение.
А при попытке выгрузить именно на Сервере 1С при запуске выгрузки думает 1 мин. и Конфигуратор говорит о мешающем сеансе Конфигуратора за номером таким то. До старта его не было и это не мой сеанс. Этот сеанс хорошо видно в утилите "Администрирование серверов 1С" в базе в разделе блокировки. Откуда он создается непонятно. Баг с выгрузкой ушел после рестарта службы Сервера 1С.
Но проблема с добавлением реквизита осталась! Если кто знает - подскажите!
-----------------------------------------------------------------
Сервер 1С:
Железо: WinXP Prof SP3 32-x / Core Quad Q8300 2.5 GHz / 3,46 Gb
Софт:
Платформа 1С: 8.2.17.143
Конфигурация: Бухгалтерия предприятия, редакция 2.0 (2.0.40.8)
-----------------------------------------------------------------
SQL:
Железо: Win 7 Prof 64-x / Core i5-3470 3.2 GHz / 16 Gb
Софт: MS SQL 2005 (9.00.1399)
(81) CaSH_2004, Я чего-то не понимаю или фраза "The transaction log for database 'accnt' is full." означает, что переполнен лог файл? Случаем не стоит ограничение на размер файла *.lg? Или может на диске, на котором хранятся файлы с логами место закончилось? Или на диске с тмп базой?
Сотрудники 1С рекомендуют решать проблему так:
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду "Проверка конфигурации" с установленным флажком "Проверка логической целостности конфигурации". При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду "Проверка конфигурации" с установленным флажком "Проверка логической целостности конфигурации". При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
Похожую проблему решил для не типовой конфигурации путем, отключения регламентных заданий, снятия с поддержки, и поставкой на поддержку заново из соответствующей конфигурации поставщика. Проблема возникла в результате перехода на платформу 8.2.19 после 8.2.13.
(92) bdimaw, Можно и ещё проще, просто полностью снять с тех поддержки, целиком и больше проблемы нет (у меня так работают сейчас 2 базы Бухгалтерия КОРП и 1 УПП) Пробовал для этих конфигураций ставить обратно на поддержку (и полную и с возможностью изменения), не прокатывает эта инструкция.
(93) Я наверное не правильно выразился "не типовой" - эта было "Бухгалтерия для Украины" но сильно измененная. Проблему решил следующим образом:
1. Заблокировал выполнение регламентных заданий на сервере 1С.
2. Полностью снял с поддержки. Обновил.
3. Сравнил с типовой, этого релиза, на вопрос "Поставить на поддержку" согласился.
4. В сравнении снял все галочки. Объединил.
И база спокойно выгрузилась. Сейчас делаются копии скриптом. Получаю файл dt. Провожу обновления, стандартным способом, а не через cf.
1. Заблокировал выполнение регламентных заданий на сервере 1С.
2. Полностью снял с поддержки. Обновил.
3. Сравнил с типовой, этого релиза, на вопрос "Поставить на поддержку" согласился.
4. В сравнении снял все галочки. Объединил.
И база спокойно выгрузилась. Сейчас делаются копии скриптом. Получаю файл dt. Провожу обновления, стандартным способом, а не через cf.
(94) bdimaw, "...Сейчас делаются копии скриптом...", а подскажи, копии скриптом, это просто типа батника с указанием параметра "/DumpIB"? И всё? Просто у меня после таких же камланий с бубном (делал всё, кроме рег. заданий, они у меня изначально отключены на сервере) данная команда не проходит, вылетает с ошибкой ... для бухгалтерии корп правда помогает перезагрузка сервера 1С, но не всегда и не на долго, а вот переделанной немного УПП это вообще не помогает, если база не снята с тех поддержки. Приходится получать CF файл типовой конфы и сравнивать с ним постоянно при обновлении.
(96) bdimaw, Да собственно на чем он написан, не так уж принципиально. И что именно кроме самой выгрузки базы делает, тоже в данном случае не важно. Мне интересен именно сам процесс выгрузки базы. Какими средствами? Типовой командой на выгрузку или же каким-то хитрым способом выдергивая дт файлы?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот