При сохранении конфигурации произошла ошибка повторить сохранение конфигурации

Или какие еще варианты есть?

(0) [ошибка потока]

  что-то мешает почистить кэш ?

Файловая БП 3.0,

дальше можно не продолжать… жмотов у которых нет денег даже на упс а тем более целых 15 тр на сервер 1с надо учить…

(0) Стаж: 4 года 6 месяцев 11 дней

а копии перед обновлением делать не научился… Ну, теперь будешь умнее.

(1) Не в кеше дело.

(2) Жлобье оно и в африке жлобье.

Но интересуют варианты вытащить данные.

(0)

Ну попробуй в chdbfl.exe проверить.

ВАЖНОЕ ПЫСЫ:

База не моя, контора не моя, я не при делах.

Позвонили, попросили посмотреть.

(10) Бекап мертвее базы. Причем все мертвые.

(11) Именно так.

(9) Уверен что нет. Делают из спортивного интереса. Смогу или нет.

(18) Это под вопросом. )

(19) Архивы все мертвые. При загрузке «» Недостаточно фактических параметров, таблица _sys чегото там тратата»

(24) Конечно.

Нашел архив от июля. Щас его развернул. попробую в него данные перелить новые.

Почему то выгрузка/загрузка черех ХМЛ не работает. База приемник говорит — неверный формат файла.

ДАйте кто нибудь выгрузку закгрузку между идентичными базами. Маней нет.

Желательно под УФ.

kurguzovvlad@gmail.com

(28) Оказались бюджетниками.

(27) То что гуглится, либо платное, либо не под УФ.

(34) 1с тулз?

Я знаю что можно — только вот нужно больше инфы.

Вот нашел, посмотрите кто понимает.

http://screencast.com/t/E6HXuyGjuF

Вот что происходит при входе в конфигуратор

http://screencast.com/t/XbzZcnvdT

Balabass

42 — 15.01.15 — 12:58

Файл не обнаружен ‘v8srvr://dbeng8/f06a5b5d8/configsave/0f9df01f-453a-47be-a793-b0a1254d2df9.0.new’

по причине:

Файл не обнаружен ‘ConfigSavef9df01f-453a-47be-a793-b0a1254d2df9.0.new’

Поводом к написанию данной статьи, послужило падение базы во время сохранения конфигурации, при динамическом обновлении. Казалось бы сколько уже раз предупреждали — «Не делайте динамическое обновление на 8.2!», но иногда, без него просто не обойтись.

Итак ничего не предвещало беды, но вдруг во время сохранения конфигурации, 1С выдала ошибку про поврежденный Config и благополучно закрылась. Думая, что проблема решится очень просто, я заново открыл Конфигуратор и прочитал следующее сообщение:

«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

Все еще пребывая в радостном расположении духа, я нажал на «Да». 1С-ка немного задумалась и выдала новое сообщение:

«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

И после нажатия на кнопку «Ок» это окно закрылось вместе с конфигуратором. Вот тут-то я и начал подозревать, что все будет не так просто.

Первым делом я полез на mista и infostart в поисках если не решения, то хотя бы причины данной проблемы, но почти все советовали одно и тоже: «Восстанавливай базу из бэкапа». Бэкап, конечно же имелся, но с одним нюансом — больше чем за половину дня, 2000 пользователей, сделали кучу документов и прочей полезной работы, а бэкап был только по состоянию на утро, да и восстановление базы, размером более 100 Гб, занимает ну оооочень продолжительное время.

Продолжая копать глубже, я наткнулся вот на эту замечательную статью VanDiesel1. Вот только этот метод не работает, если базы находятся в разных кластерах, но немного подумав я все же нашел решение. Прочитав статью я узнал, что все дело в «испортившихся» таблицах dbo.Config и dbo.ConfigSave.

Итак, отставить панику!

1. Проверяем есть ли у нас конфигурация идентичная рухнувшей. В моем случае, их было целых 4, так как работаем через Хранилище Конфигурации. Можно использовать и не совсем идентичную конфигурацию, но будьте готовы к тому, что тогда все изменения придется вносить заново (если конечно у вас нет Хранилища Конфигурации).

2. Далее заходим в SQL Management Studio и очищаем таблицы dbo.Config и dbo.ConfigSave рухнувшей базы с помощью нехитрого запроса (для того чтобы его написать, нажмите «New Query» или «Новый Запрос», ну а чтобы выполнить — «Execute» и «Выполнить» соответственно):

Truncate table dbo.Config

Truncate table dbo.ConfigSave

3. Все, теперь осталось «залить» эти же таблицы из хорошей конфигурации. Как я уже написал выше, способ предложенный VanDiesel1 мне не помог, так как рабочая база и все базы с хорошими конфигурациями, находились в разных кластерах. Почитав мануал к SQL Management Studio, я наткнулся на такую возможность, как импорт таблиц из одной базы в другую и незамедлительно решил ей воспользоваться. Итак в SQL Management Studio становимся на испорченную базу и щелкаем правой кнопкой мыши, далее Tasks -> Import Data.

Откроется визард в котором:

• a) На второй странице указываем сервер и базу из которой мы будем брать данные.
• b) На третьей указываем базу приемник.
• с) На четвертой выбираем «Копировать данные из таблиц».
• d) На пятой отмечаем галками таблицы dbo.Config и dbo.ConfigSave.
• e) На шестой смотрим, чтобы не было ошибок и процесс загрузки прошел успешно.

4. Вот собственно и все, можно пробовать запускать 1С.   

P.S. В ходе поиска решения узнал, что этот способ восстановления, является недокументированным 1С и все действия, вы выполняете на свой страх и риск, а документированный способ — это восстановление из бэкапа.

Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы.

Ошибка возникает после динамического обновления.

При запуске 1с сначала выходит диалог с ошибкой «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление». 

Если попытаться обновить, бывает два варианта сценария

• все применяется корректно, но потребуется завершить работу пользователей для обновления
• обновление не проходит: выходит сообщение («Обнаружена незавершенная операция сохранения конфигурации«)

Причины и обстоятельства

Такие ошибки возникают обычно на старых версиях платформы. В настоящее они время проявляются очень редко (на 8.3 не встречалось ни разу).

Также замечу: в последней платформе 8.3.8 появилось долгожданное динамическое обновление в клиент-серверном режиме без перезапуска конфигуратора (ранее такое было только на файловых базах).

Можно долго говорить о том, что не надо пользоваться динамическим обновление, необходимо организовывать работу так, чтобы это происходило реже, но это документированный функционал платформы, соответственно он должен работать корректно.

Что же делать при такой ошибке?

• запомнить/записать точное время возникновения ошибки.
• сообщить всем о том, что ошибка известна, вы работаете над ее решением и база некоторое время работать не будет (далее игнорируете всех, кто не может вам помочь иначе вас затерроризируют вопросами)
• сделать полную копию базы данных
• развернуть(открыть) копию базы, где конфигурация соответствует составу реквизитов (они должны совпадать), код модулей и форм может отличаться (быть не актуальным)
• если есть отличия в реквизитах постараться «свести» конфигурации

Если копий нет, то в случае если конфигурация типовая и правки не затрагивают структуру данных, то разворачивайте типовую конфигурацию.

Далее, производите замещение конфигурации из «копии» в «исправляемую» базу

Для этого Запускаете SQL Management Studio и выполняете такой запрос:

delete  from [ИмяИсправляемойБазы].[dbo].[Config]

GO

insert into [ИмяИсправляемойБазы].[dbo].[Config]
SELECT [FileName]
      ,[Creation]
      ,[Modified]
      ,[Attributes]
      ,[DataSize]
      ,[BinaryData]
  FROM [КопияБазы].[dbo].[Config]
GO

В 99% случаев он вам поможет (мне помогало 3 раза). Исправление занимало от 5 до 20 минут.

Далее восполняете пробелы в коде. Если конфигурация подключена к хранилищу, необходимо синхронизировать захваченные объекты (отпустить и захватить заново), внести правки.

Если версия файловая произведите тестирование утилитой «C:Program Files (x86)1cv88.*.*.*binchdbfl.exe».

При отсутствии конфигурации/копии:

• смотрите записи таблицы dbo.ConfigSave, при наличии — очищайте (пробуйте запустится)
• смотрите записи таблицы Config, на поле «FileName», если есть со значением «commit»,»dbStruFinal» или «dynamicCommit»  — удаляйте
• либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется «по манипулировать» с датами и именами, но у меня не получалось)

Не помогло?

В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).

При небольшом документообороте может оказаться проще откатить базу на несколько минут назад — быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.

Рекомендации

• Используйте полную модель восстановления
• Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
• Используйте хранилище для разработки
• Держите рядом копию базы (это сэкономит время для восстановления)
• При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях

В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления — с вытекающими проблемами.

Войти или зарегистрироваться