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

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

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

Речь пойдет о файловом варианте работы с хранилищем.

 

1. Ошибка аутентификации в хранилище конфигурации

Самая понятная из возможных ошибок. Данная ошибка возникает при вводе неверного логина и пароля.

Изменить логин и пароль может пользователь с административными правами на вкладке "Пользователи" окна "Администрирование хранилища конфигурации"

 

2. Пользователь существующей связи отличается от текущего

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

Данная ошибка возникает, когда текущая база уже подключена к хранилищу под каким-то логином, а вы пытаетесь ввести другой логин. Это может быть по разным причинам:

  • вы зашли в общую базу и пытаетесь войти под своим логином хранилища. Необходимо выяснить логин этой конкретной базы, и заходить под ним, но не переподключать под своим. Посмотреть, под каким логином подключена каждая база может пользователь с административными правами в хранилище, на вкладке "Подключения" окна "Администрирование хранилища конфигурации"
  • вы развернули базу, которая уже была подключена к хранилищу. Необходимо отключить конфигурацию от хранилища и подключить заново.

 

3. Пользователь уже аутентифицирован в хранилище

Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. И с ней работают под этим логином в данный момент.

При такой ошибке вы не сможете подключиться под введенным логином. Необходимо подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.

 

4. Для данного пользователя уже имеется конфигурация связанная с данным хранилищем конфигурации

Предупреждение похоже на ошибку из предыдущего пункта, но есть небольшое отличие.

Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. Но с ней не работают под этим логином в данный момент.

Предупреждение позволяет подключиться под введенным логином, но нужно понимать последствия. Если вы подключитесь под эти логином, то у другого пользователя рано или поздно возникнет ошибка из предыдущего пункта или аналогичное предупреждение. Рекомендую подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.

 

5. При получении данных из хранилища или захвате объекта: Не удалось зафиксировать таблицу для чтения "Versions"

Данная ошибка возникает, когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.

Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.

 

6. При подключении к хранилищу: Не удалось зафиксировать таблицу для чтения "Users"

Данная ошибка может возникать:

  • когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.

Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.

  • когда в этот самый момент другой пользователь помещает большой объем данных в хранилище

Необходимо подождать, пока другой пользователь закончит помещение объектов в хранилище.

 

7. Файл не является файлом базы данных

Ошибка соединения с хранилищем конфигурации по адресу:
\ServerRepositoryproject1
по причине:
Файл не является файлом базы данных ‘//Server/Repository/project1/1cv8ddb.1CD’

Данная ошибка может возникать при подключении к хранилищу:

  •  если есть зависший фоновый процесс к этой базе.

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

  • если есть зависший сеанс другой базы, подключенной к этому хранилищу на этом компьютере

Так бывает, что одновременно приходится работать с разными базами в одном хранилище. Если про одну базу надолго забыть, и в ней будет появляться ошибка №5, то другую базу с этим хранилищем вы открыть не сможете. Необходимо завершить "забытые" сеансы.

8. Файл базы данных поврежден.

Ошибка соединения с хранилищем конфигурации по адресу: 
\ServerRepositoryproject1
по причине: 
Файл базы данных поврежден ‘\ServerRepositoryproject1//1cv8ddb.1CD’ 

 

Данная ошибка может возникать:

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

 

Алгоритм решения:

1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу

2. Почистить кэш хранилища

3. Одному запустить конфигуратор от имени администратора

4. Подключиться к хранилищу

Если указанные действия не помогли, можно воспользоваться утилитой chdbfl.exe, но в моей памяти мне она ни разу не помогла и единственным выходом было создание хранилища с нуля.

 

9. Неклассифицированная ошибка работы с хранилищем конфигурации

Данная ошибка может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529 

Алгоритм решения:

1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу

2. Очистить глобальный кэш хранилища

3. Синхронизировать версии платформ.

 

Это, конечно, не весь список ошибок, который может возникать при работе с хранилищем. Я привёл те ошибки, с которыми я лично не раз сталкивался и решал указанными мной способами. Если у вас есть ошибка, которая не описана, и вы знаете способ ее решения, пишите в комментарий, я с удовольствием добавлю информацию в общую статью.

19 Comments

  1. user716065

    По п.4 — ошибка может появляться также: когда вы для себя разворачиваете копию в базу с которой до этого работали (типа актуализация базы данных). Решение: отключиться от хранилища и снова подключиться к хранилищу под тем же самым логином и паролем.

    Reply
  2. user716065

    Ай плохо прочитал: решение вами описано в п.3

    Reply
  3. kuzyara

    И самое больное: если вы пришли с утра и на операцию с хранилищем 1с зависает на >10секунд, то значит ночью падала сеть и см. п.7.

    Reply
  4. Артано

    п. 8. Файл базы данных поврежден. Может воспроизводиться при проблемах с соединением. Проверить сеть. Перезайти в конфигуратор

    Reply
  5. info1i

    Не раз бывало, что пропадали отдельные куски кода, целые разработки из истории хранилища после, примерно, месяца-двух работы. Только не надо про кэш и т.п… Пришлось настроить в планировщике ежедневную архивацию папки с хранилищем.

    Reply
  6. Xershi

    (5) скорее всего работали не один и с хранилищем не умеете работать!

    Reply
  7. info1i

    (6) Я же просил, не надо т.п… 🙂 Так бывало, бывало не раз, не у меня одного; код пропадает не последний, а где-то из середины истории; возможно, платформа, но опыт теперь заставляет архивировать.

    Reply
  8. info1i

    (7) Добавлю: окончательно в столь редком баге убедился, когда распаковал архивную папку и нашел в ней пропавшую разработку, примерно коммитов 4-7 назад перед последним.

    Reply
  9. info1i

    (9) Пожалуйста, вместо слова «криво работают» лучше напишите, в каких случаях такую ситуацию можно воспроизвести — это будет более конструктивно и по теме статью, полезнее.

    Reply
  10. vasilev2015

    (9)

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

    Давайте украшать (полит)корректностью и конструктивизмом каждый комментарий ))).

    Reply
  11. wizard.ilmir02

    (8) Данная проблема возникает если захватывать и изменять объект метаданных в рабочей базе, накатывая изменения динамическим обновлением. После этого при помещение в хранилище будет помещаться не реальные изменения в конфигураторе, а кеш самого старого активного пользователя в базе.

    Reply
  12. kansler

    решение для п.3. Если все выйдут из конфигураторов, подключенных к хранилищу, то потом снова можно зайти под своим логином. Т.е. эта проблема возникает совсем не обязательно из-за того, что под твоим логином кто-то другой зашел.

    Reply
  13. sergey_garin

    Бывает такое:

    «Неклассифицированная ошибка работы с хранилищем конфигурации»

    Может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529

    Решение: очистить глобальный кэш хранилища и синхронизировать версии платформ.

    Reply
  14. rudnitskij

    (10) Работаю с несколькими базами на разных серверах, описанную вами проблему наблюдаю только на одной. Причем с периодичностью раз в два-три месяца

    Reply
  15. user1162192

    Спасибо, помог по п. 7

    Reply
  16. gubanoff

    (0) для решения проблемы 7) с зависшими подключениями у себя сделали следующее:

    — вынесли хранилище в отдельную виртуалку

    — настроили ночную перезагрузку виртуалки, чтобы закрывались соединения

    — после загрузки добавили скрипт, который удаляет все временные файлы из каталога хранилища.

    Reply
  17. hasp_x

    не подскажите, как почистить кэш хранилища?

    Reply
  18. Смешной 1С

    (19)

    — Сначала всем завершить работу с хранилищем,

    — затем зайти в каталог хранилища, сделать его бэкап

    — в каталоге есть папка «cache«. Нужно почистить ее содержимое.

    Reply
  19. hasp_x

    (20) спасибо, но у нас и это не помогло, помог радикальный метод — скопировали папку хранилища в другую папку и сообщили всем пользователем о новом хранилище

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *