Ошибки при работе с хранилищем конфигурации и способы их решения

0. Смешной 1С 381 01.03.19 18:46 Сейчас в теме
В статье собраны наиболее распространенные ошибки при работе с хранилищем конфигурации и способы их обхода и решения.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user716065 9 02.03.19 08:41 Сейчас в теме
По п.4 - ошибка может появляться также: когда вы для себя разворачиваете копию в базу с которой до этого работали (типа актуализация базы данных). Решение: отключиться от хранилища и снова подключиться к хранилищу под тем же самым логином и паролем.
2. user716065 9 02.03.19 08:43 Сейчас в теме
Ай плохо прочитал: решение вами описано в п.3
3. kuzyara 1055 04.03.19 04:31 Сейчас в теме
И самое больное: если вы пришли с утра и на операцию с хранилищем 1с зависает на >10секунд, то значит ночью падала сеть и см. п.7.
4. Артано 673 04.03.19 10:43 Сейчас в теме
п. 8. Файл базы данных поврежден. Может воспроизводиться при проблемах с соединением. Проверить сеть. Перезайти в конфигуратор
5. info1i 87 05.03.19 01:16 Сейчас в теме
Не раз бывало, что пропадали отдельные куски кода, целые разработки из истории хранилища после, примерно, месяца-двух работы. Только не надо про кэш и т.п... Пришлось настроить в планировщике ежедневную архивацию папки с хранилищем.
ZUL_MTFKA; +1 Ответить
6. Xershi 1018 05.03.19 01:19 Сейчас в теме
(5) скорее всего работали не один и с хранилищем не умеете работать!
7. info1i 87 05.03.19 01:32 Сейчас в теме
(6) Я же просил, не надо т.п... :) Так бывало, бывало не раз, не у меня одного; код пропадает не последний, а где-то из середины истории; возможно, платформа, но опыт теперь заставляет архивировать.
8. info1i 87 05.03.19 01:38 Сейчас в теме
(7) Добавлю: окончательно в столь редком баге убедился, когда распаковал архивную папку и нашел в ней пропавшую разработку, примерно коммитов 4-7 назад перед последним.
12. wizard.ilmir02 105 06.03.19 18:57 Сейчас в теме
(8) Данная проблема возникает если захватывать и изменять объект метаданных в рабочей базе, накатывая изменения динамическим обновлением. После этого при помещение в хранилище будет помещаться не реальные изменения в конфигураторе, а кеш самого старого активного пользователя в базе.
Sander80; zqzq; Rego1337h; Boyborodin; AntonSm; +5 Ответить
27. Sander80 81 28.04.20 08:55 Сейчас в теме
(12) похоже на правду. Такие сбои перестали случаться после того, как отказались от подключения основной базы к хранилищу - ее теперь обновляем через сравнение-объединение с хранилищем, выделенный пользователь хранилища для этого есть, но не подключена.

Мне кажется, это должно быть рекомендованным способом работы с хранилищем.
9. Xershi 1018 05.03.19 09:07 Сейчас в теме
(7) да пропадает именно не последний. И такие горе разработчики удивляются как так. А все потому что криво работают...
10. info1i 87 05.03.19 09:10 Сейчас в теме
(9) Пожалуйста, вместо слова "криво работают" лучше напишите, в каких случаях такую ситуацию можно воспроизвести - это будет более конструктивно и по теме статью, полезнее.
16. rudnitskij 11.03.19 15:35 Сейчас в теме
(10) Работаю с несколькими базами на разных серверах, описанную вами проблему наблюдаю только на одной. Причем с периодичностью раз в два-три месяца
11. vasilev2015 1892 06.03.19 08:48 Сейчас в теме
(9)
Куски кода при работе с хранилищем могут теряться из-за проблем с локальным кэшем конфигурации, когда база разработчика вообще теряет связь с действительностью.
Давайте украшать (полит)корректностью и конструктивизмом каждый комментарий ))).
13. Xershi 1018 07.03.19 00:15 Сейчас в теме
(11) да. Это основная проблема когда делают все правильно.
Но есть другая, когда вместо получить жмут захватить. А потом удивляются что хранилище не так работает!
14. kansler 09.03.19 19:03 Сейчас в теме
решение для п.3. Если все выйдут из конфигураторов, подключенных к хранилищу, то потом снова можно зайти под своим логином. Т.е. эта проблема возникает совсем не обязательно из-за того, что под твоим логином кто-то другой зашел.
15. sergey_garin 11.03.19 09:45 Сейчас в теме
Бывает такое:
«Неклассифицированная ошибка работы с хранилищем конфигурации»

Может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529
Решение: очистить глобальный кэш хранилища и синхронизировать версии платформ.
Прикрепленные файлы:
DrAku1a; Смешной 1С; +2 Ответить
17. user1162192 24.04.19 13:27 Сейчас в теме
18. gubanoff 50 17.06.19 11:56 Сейчас в теме
(0) для решения проблемы 7) с зависшими подключениями у себя сделали следующее:
- вынесли хранилище в отдельную виртуалку
- настроили ночную перезагрузку виртуалки, чтобы закрывались соединения
- после загрузки добавили скрипт, который удаляет все временные файлы из каталога хранилища.
19. hasp_x 154 09.10.19 12:22 Сейчас в теме
не подскажите, как почистить кэш хранилища?
20. Смешной 1С 381 09.10.19 12:25 Сейчас в теме
(19)
- Сначала всем завершить работу с хранилищем,
- затем зайти в каталог хранилища, сделать его бэкап
- в каталоге есть папка "cache". Нужно почистить ее содержимое.
байт; +1 Ответить
21. hasp_x 154 10.10.19 10:15 Сейчас в теме
(20) спасибо, но у нас и это не помогло, помог радикальный метод - скопировали папку хранилища в другую папку и сообщили всем пользователем о новом хранилище
26. байт 87 27.04.20 10:16 Сейчас в теме
(21) Может пользовательский кэш почистить просто нужно было?
22. FilippSerg 09.01.20 12:06 Сейчас в теме
Вот еще "Информационная база не связана с хранилищем конфигурации"
Приходится отключать базу от хранилища и заново подключать: Конфигурация - Хранилище конфигурации - Отключиться от хранилища, затем Подключиться к хранилищу.
Если в основную конфигурацию были внесены изменения, то до подключения её можно выгрузить в файл, а после подключения загрузить обратно и тогда уже поместить изменения в хранилище.
Возможно версия конфигурация хранилища не будет совпадать с конфигурацией базы данных, при необходимости можно провести сравнение и привести основную конфигурацию к нужному виду.
Прикрепленные файлы:
23. AlekseyBelyy 22.04.20 09:28 Сейчас в теме
Всем привет. Часто возникает ошибка №7.
Ошибка соединения с хранилищем конфигурации по адресу:
\\**********\store\torg
по причине:
Файл не является файлом базы данных '//**********/store/torg/1cv8ddb.1CD'

У нас две виртуалки - старый и новый - серваки для разработки. Хранилище расположено на новом в общей папке, база подключенная к хранилищу подключена на старой серваке и скульно, и в кластере 1С, в конфигураторе работаю с хранилищем здесь же.
Всегда когда перегружают новый сервак (ребут винды именно), где лежит хранилище, в моей базе проблема №7 возникает, но при чем если первые пару раз я не закрывал конфигуратор, открытый на старом серваке. То недавно закрыл и конф, и предприятие и все равно эта долбанная ошибка как перегрузят сервак на котором хранилище живет. Помогает только перезагрузка старого сервака, с которого я работаю.
Пробовал много чего и кеш чистить, службу рагента перезапускать, соединения зависшие искать к хранилищу. Только перезагрузка помогает.
У кого-нибудь мысли есть почему так?
24. Смешной 1С 381 22.04.20 14:02 Сейчас в теме
(23) Второй вариант возникновения этой проблемы описывал так: если есть зависший сеанс другой базы, подключенной к этому хранилищу на этом компьютере.

Есть ли у вас другие люди, которые также работают на старом серваке, подключенные к этому хранилищу? Если да, тогда при перезагрузке нового сервака, их сеансы остаются висеть, даже несмотря на то, что свой сеанс конфигуратора вы преждевременно завершили. Завершать должны все на компьютере, тогда зависших сеансов к хранилищу не будет.
user1181356; +1 Ответить
25. dock 41 27.04.20 08:22 Сейчас в теме
28. user1181356 01.09.20 06:37 Сейчас в теме
Спасибо тебе, Смешной 1С! Была ошибка №7 и дело, действительно было в зависших фоновых процессах.
Гениально, ветку в коллекцию.
Оставьте свое сообщение
Вопросы с вознаграждением