1с информационная база не связана с хранилищем конфигурации
добрый день, подключаюсь к хранилищу а выдает "информационная база не связана с хранилищем конфигурации", надо просто отключиться от него и заново подключится пишут, просто это пишет на рабочей конфигурации, ничего страшного не произойдет)?
Произойдёт. Конфа будет полностью заменена на конфу из хранилища. Но если в хранилище лежит актуальная версия, и в рабочей базе - она же, то всё должно быть в порядке.
только надо выгрузить сф конфигурации рабочей и сравнить на другой базе которая подключена к хранилищу?
Смейтесь. Только вот доступа разработчикам к реальным данным у нас нет. Вообще. Для этого и существует тестовая, а на рабочую изменения накатывают совсем другие люди, посредством поставки.
Все правильно. Вагон носителей незамутненного сознания что-то наколотили в хранилище. После этого ответственное лицо проверяет, можно ли поднимать изменения или это лажа. Если можно, то поднимает. Как ваша бесправность противоречит тому, что рабочую можно и вполне себе нужно обновлять из хранилища? Кто сказал, что это должен делать именно тот, кто поместил что-то в хранилище?
Рабочая среда вообще изолирована от среды разработки и хранилища. Совсем. Так что мы имеем первое затруднение. Второе, кто-то кто обновляет - именно он должен являться администратором хранилища, теоретически может не иметь ни малейшего отношения к 1С. P.S. Я не утверждаю что описанный мной способ является единственно верным. Просто описываю реалии того что я видел/пользовал и не единожды.
Если изолирована - то в чём вопрос? Делайте, как удобнее. Хранилище - вполне нормальное решение, если реалии от ваших отличаются.
Я по удаленке работал на две мегакрупные масковские конторы, где юзали хранилище. В первой рабочая база была подключена к хранилищу, во второй нет (доступ был полный), архитектор был один и тот же и именно он принимал решение не подключать рабочую базу во второй конторе к хранилищу, т.к. оно (хранилище) постоянно глючит.
В написано, что к хранилищу подключена тестовая. Что не в тему, потому что мы говорим про подключенность или неподключенность к хранилищу рабочей. В констатация того, что вам не дают доступ к рабочей (опять же, причем здесь это?) и того, что в вашем случае кто-то там обновляет все из поставки (опять же, как ваш конкретный случай вдруг делает неправильным подключение рабочей базы к хранилищу?). В опять же какие-то рассказы про конкретные ситуации, после чего фраза про то, что все это твой личный опыт, а не претензия на наиболее правильный вариант. Спрашивается, мы здесь делимся опытом, у кого как или выясняем, какой вариант наиболее правильный?
Я для себя сделал вывод что подключение рабочей базы к хранилищу (как и демоническое обновление) лучше не юзать, от греха подальше.
"т.к. оно (хранилище) постоянно глючит." Мда, у кого-то и винда кривая и стул скрипучий и 1С глюкавая :))
добрый день, подключаюсь к хранилищу а выдает "информационная база не связана с хранилищем конфигурации", надо просто отключиться от него и заново подключится пишут, просто это пишет на рабочей конфигурации, ничего страшного не произойдет)?
(0) Произойдёт. Конфа будет полностью заменена на конфу из хранилища. Но если в хранилище лежит актуальная версия, и в рабочей базе - она же, то всё должно быть в порядке.
(1) спасибо за разъяснения, а можно как-то проверить перед тем как подключаться актуальная ли версия?
(2) только надо выгрузить сф конфигурации рабочей и сравнить на другой базе которая подключена к хранилищу?
(12) Смейтесь. Только вот доступа разработчикам к реальным данным у нас нет. Вообще. Для этого и существует тестовая, а на рабочую изменения накатывают совсем другие люди, посредством поставки.
(13) Все правильно. Вагон носителей незамутненного сознания что-то наколотили в хранилище. После этого ответственное лицо проверяет, можно ли поднимать изменения или это лажа. Если можно, то поднимает.
Как ваша бесправность противоречит тому, что рабочую можно и вполне себе нужно обновлять из хранилища?
Кто сказал, что это должен делать именно тот, кто поместил что-то в хранилище?
(14) Рабочая среда вообще изолирована от среды разработки и хранилища. Совсем. Так что мы имеем первое затруднение. Второе, кто-то кто обновляет - именно он должен являться администратором хранилища, теоретически может не иметь ни малейшего отношения к 1С.
P.S. Я не утверждаю что описанный мной способ является единственно верным. Просто описываю реалии того что я видел/пользовал и не единожды.
(16) Если изолирована - то в чём вопрос? Делайте, как удобнее. Хранилище - вполне нормальное решение, если реалии от ваших отличаются.
Я по удаленке работал на две мегакрупные масковские конторы, где юзали хранилище. В первой рабочая база была подключена к хранилищу, во второй нет (доступ был полный), архитектор был один и тот же и именно он принимал решение не подключать рабочую базу во второй конторе к хранилищу, т.к. оно (хранилище) постоянно глючит.
(16) В (8) написано, что к хранилищу подключена тестовая. Что не в тему, потому что мы говорим про подключенность или неподключенность к хранилищу рабочей.
В (13) констатация того, что вам не дают доступ к рабочей (опять же, причем здесь это?) и того, что в вашем случае кто-то там обновляет все из поставки (опять же, как ваш конкретный случай вдруг делает неправильным подключение рабочей базы к хранилищу?).
В (16) опять же какие-то рассказы про конкретные ситуации, после чего фраза про то, что все это твой личный опыт, а не претензия на наиболее правильный вариант.
Спрашивается, мы здесь делимся опытом, у кого как или выясняем, какой вариант наиболее правильный?
В статье собраны наиболее распространенные ошибки при работе с хранилищем конфигурации и способы их обхода и решения.
По п.4 - ошибка может появляться также: когда вы для себя разворачиваете копию в базу с которой до этого работали (типа актуализация базы данных). Решение: отключиться от хранилища и снова подключиться к хранилищу под тем же самым логином и паролем.
И самое больное: если вы пришли с утра и на операцию с хранилищем 1с зависает на >10секунд, то значит ночью падала сеть и см. п.7.
п. 8. Файл базы данных поврежден. Может воспроизводиться при проблемах с соединением. Проверить сеть. Перезайти в конфигуратор
Не раз бывало, что пропадали отдельные куски кода, целые разработки из истории хранилища после, примерно, месяца-двух работы. Только не надо про кэш и т.п. Пришлось настроить в планировщике ежедневную архивацию папки с хранилищем.
(6) Я же просил, не надо т.п. :) Так бывало, бывало не раз, не у меня одного; код пропадает не последний, а где-то из середины истории; возможно, платформа, но опыт теперь заставляет архивировать.
(7) Добавлю: окончательно в столь редком баге убедился, когда распаковал архивную папку и нашел в ней пропавшую разработку, примерно коммитов 4-7 назад перед последним.
(8) Данная проблема возникает если захватывать и изменять объект метаданных в рабочей базе, накатывая изменения динамическим обновлением. После этого при помещение в хранилище будет помещаться не реальные изменения в конфигураторе, а кеш самого старого активного пользователя в базе.
(12) похоже на правду. Такие сбои перестали случаться после того, как отказались от подключения основной базы к хранилищу - ее теперь обновляем через сравнение-объединение с хранилищем, выделенный пользователь хранилища для этого есть, но не подключена.
Мне кажется, это должно быть рекомендованным способом работы с хранилищем.
(7) да пропадает именно не последний. И такие горе разработчики удивляются как так. А все потому что криво работают.
(9) Пожалуйста, вместо слова "криво работают" лучше напишите, в каких случаях такую ситуацию можно воспроизвести - это будет более конструктивно и по теме статью, полезнее.
(10) Работаю с несколькими базами на разных серверах, описанную вами проблему наблюдаю только на одной. Причем с периодичностью раз в два-три месяца
(9)
Куски кода при работе с хранилищем могут теряться из-за проблем с локальным кэшем конфигурации, когда база разработчика вообще теряет связь с действительностью.
Давайте украшать (полит)корректностью и конструктивизмом каждый комментарий ))).
(11) да. Это основная проблема когда делают все правильно.
Но есть другая, когда вместо получить жмут захватить. А потом удивляются что хранилище не так работает!
решение для п.3. Если все выйдут из конфигураторов, подключенных к хранилищу, то потом снова можно зайти под своим логином. Т.е. эта проблема возникает совсем не обязательно из-за того, что под твоим логином кто-то другой зашел.
Бывает такое:
«Неклассифицированная ошибка работы с хранилищем конфигурации»
Может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529
Решение: очистить глобальный кэш хранилища и синхронизировать версии платформ.
(0) для решения проблемы 7) с зависшими подключениями у себя сделали следующее:
- вынесли хранилище в отдельную виртуалку
- настроили ночную перезагрузку виртуалки, чтобы закрывались соединения
- после загрузки добавили скрипт, который удаляет все временные файлы из каталога хранилища.
(19)
- Сначала всем завершить работу с хранилищем,
- затем зайти в каталог хранилища, сделать его бэкап
- в каталоге есть папка " cache ". Нужно почистить ее содержимое.
(20) спасибо, но у нас и это не помогло, помог радикальный метод - скопировали папку хранилища в другую папку и сообщили всем пользователем о новом хранилище
Вот еще "Информационная база не связана с хранилищем конфигурации"
Приходится отключать базу от хранилища и заново подключать: Конфигурация - Хранилище конфигурации - Отключиться от хранилища, затем Подключиться к хранилищу.
Если в основную конфигурацию были внесены изменения, то до подключения её можно выгрузить в файл, а после подключения загрузить обратно и тогда уже поместить изменения в хранилище.
Возможно версия конфигурация хранилища не будет совпадать с конфигурацией базы данных, при необходимости можно провести сравнение и привести основную конфигурацию к нужному виду.
Всем привет. Часто возникает ошибка №7.
Ошибка соединения с хранилищем конфигурации по адресу:
\\**********\store\torg
по причине:
Файл не является файлом базы данных '//**********/store/torg/1cv8ddb.1CD'
У нас две виртуалки - старый и новый - серваки для разработки. Хранилище расположено на новом в общей папке, база подключенная к хранилищу подключена на старой серваке и скульно, и в кластере 1С, в конфигураторе работаю с хранилищем здесь же.
Всегда когда перегружают новый сервак (ребут винды именно), где лежит хранилище, в моей базе проблема №7 возникает, но при чем если первые пару раз я не закрывал конфигуратор, открытый на старом серваке. То недавно закрыл и конф, и предприятие и все равно эта долбанная ошибка как перегрузят сервак на котором хранилище живет. Помогает только перезагрузка старого сервака, с которого я работаю.
Пробовал много чего и кеш чистить, службу рагента перезапускать, соединения зависшие искать к хранилищу. Только перезагрузка помогает.
У кого-нибудь мысли есть почему так?
(23) Второй вариант возникновения этой проблемы описывал так: если есть зависший сеанс другой базы, подключенной к этому хранилищу на этом компьютере .
Есть ли у вас другие люди, которые также работают на старом серваке, подключенные к этому хранилищу? Если да, тогда при перезагрузке нового сервака, их сеансы остаются висеть, даже несмотря на то, что свой сеанс конфигуратора вы преждевременно завершили. Завершать должны все на компьютере, тогда зависших сеансов к хранилищу не будет.
В данной статье описывается, как установать службу сервера хранилища конфигураций 1С:Предприятия.
Цитата из RTFM
В целом, если надо просто установить службу и, чтобы всё взяло и начало работать, достаточно просто почитать addoc (см ниже).
Для установки сервиса достаточно запустить crserver.exe с параметром -instsrvc и параметрами же указать, где что лежит и так делее. Все тривиально и в мануале описано достаточно подробно.
Как установить два сервера на одной машине
Заморочки начинаются, когда надо установить больше одной службы сервера хранилища. Например - для разных версий платформы или для организации на одном сервере хранилищ для не связанных команд разработчиков. Возможных причин на самом деле море. Суть заморочек в том, что crserver.exe может установаить одну и только дону службу - у него нет параметра командной строки, влияющего на имя службы.
Для управления службами в Windows, начиная с NT4, существует замечательная консольная утилта SC.EXE. По ссылке можно найти исчерпывающий мануал по командам. Единственное, что стоит к этому мануалу добавить – имя параметра включает символ «=» и между этим символом и значением параметра ОБЯЗАТЕЛЬНО должен быть пробел, иначе sc.exe вместо полезной работы просто покажет кратенький мануал к самому себе. Это отмечено в мануале, но в самом конце, а до конца обычно дочитывают самые стойкие и уже от отчаяния, когда 100500-й раз не получилось то, что в мануале описано буква-в-букву.
Итак, предположим, нам нужно развернуть две службы сервера. Для этого нам нужно определиться со следующими параметрами:
Имена служб - строки, которые отображаются в колонке «Имя» в диспетчере служб. Помимо отображения по имени производятся все манипуляции со службой через sc.exe по этому рекомендуется с имененм не мудрить и придумывать его максимально кратким и емким безо всяких спецсимволов
В каких каталогах будут хранить свои данные службы. Теоретически можно каталог не указывать и тогда обе службы будут «раздавать» один и тот же каталог и к каждому хранилищу можно будет обратиться из обеих служб одновременно.
На каких портах будут ожидать соединения обе службы. Службе сервера хранилища нужен один основной порт и диапазон из 31-го порта для работы. По умолчанию эти значения равны 1542 и 1560:1591. У разных экземпляров службы эти значения обязательно должны быть разные иначе работать будет только один экзепляр - тот, который успел запуститься раньше и открыть сокет на основаном порту.
Для примера предположим, что:
Командная строка для создания каждой из этих служб будет выглядеть вот так:
cmd.exe, естественно, следует запускать от имени администратора и данные команды предполагают развертывание сервера хранилища 8.2.16.368. Progra~2 - это «Programm files (x86)».
Собственно всё – дальше только нужно зайти в диспетчер служб и запустить созданные службы или использовать дя этого консольную команду net start – не важно.
Также следует отметить, что если используется IIS, то обращение к серверам хранилищ нужно реализовать через отдельные веб-приложения, причем у них должны быть указаны разные пулы приложений (например, DefaulAppPool и DefaulAppPool2). Если этого не сделать, то одновременно будет работать только один сервер хранилищ (к которому было первое обращение), а второй будет выдавать ошибку.
Что дает и чего не дает сервер хранилища 1С
Для того, чтобы внести чуть больше полноты в картину данной статьи, следует перечислить весь страх и ненависть все положительные и отрицательные стороны использования серверного хранилища.
Плюсы серверного хранилища
Порядок следования пунктов соответствует порядку, в котором они пришли в голову автору данной статьи, значимость плюсов каждый читатель определит для себя сам:
Изоляция данных от интерфейса. Разработчики «видят» только службу – ни с файлом хранилища, ни с его каталогом, они не могут сделать ни чего, кроме того, что им положено в соответствии с правами в хранилище. В файловой версии хранилища права на шару одни, а на хранилище другие: например, у пользователя, который просто есть в хранилище, но даже захватить ни чего прав не имеет, все равно должен быть полный доступ в шару, то есть он может и всякого мусора рядом с 1cd навалить, и файл повредить, и скопировать все хранилище куда угодно. Кроме того это упрощает подключение к хранилищу всякого рода удаленных разработчиков – для работы с хранилищем им достаточно открыть несколько tcp портов и можно не пускать их в свою внутреннюю сеть, а служба crserver уже не позволит им в 1cv8ddb.1CD сделать что-либо, кроме того, что можно сделать конфигуратором. Максимум - всяких левых хранлищ могут насоздавать в каталогах рядом, но это горе не большой беды, как говорится. Кроме того служба сервера гарантирует, что к хранилищу невозможно подключиться ни каким релизом платформы, отличным от релиза самой службы сервера. То есть ни кто злонамеренно или от разгильдяйства боевое хранилище случайно не сконвертирует под какой-нибудь тестовый новый релиз 8.3, 8.4 или даже 9.0 - crserver просто не пустит неправославных клиентов.
Независимость от фактического места хранения файла 1cv8ddb.1CD - можно перемещать файл и менять внутреннюю структуру каталогов и при этом у пользователей хранилища строка подключения не изменится – знай только меняй параметр -d у службы crserver. В принципе у файлового хранилища то же самое возможно, но в случае, когда хранилищ много от разных ИС, может быть так, что и не всегда получится. Или, если у всех хранилищ изначально один каталог, то разнести по разным без изменения строки подключения в файловом варианте уже не возможно.
Использование серверной мощи для операций с хранилищем. Все операции по чтению и записи в 1cv8ddb.1CD производятся службой crserver и процессором той машины, на которой она работает. В файловом варианте все операции делает процессор клиента.
Нюанс в 8.2
В 8.2.* crserver является однопроцессорным приложением. Отсюда вытекает ряд неприятных минусов, о которых ниже. В 8.2 минусы серверного хранилища по сравнению с файловым целиком и полностью произрастают из последнего «плюса». Служба crserver сама ни чего полезного не делает – она всего лишь ретранслятор запросов от клиентов. Именно по этому версия crserver должна в точности совпадать с версией клиента. И именно по этому можно расшарить каталог службы и обращаться к хранилищу и как к файловому, и как к серверному. Более того, можно даже развернуть две службы crserver, натравить их на один и тот же каталог и из двух параллельных служб всё – захваты, помещение, чтение и так далее – будет работать так же, как с одной службой или без служб вообще. Итак, вот они, «минусы»:
Однопроцессорность crserver'а. Служба crserver умеет работать только с одним процессором, по этому она, конечно, будет использовать мощу сервера, но только один процессор. Если пользователей много, то она выстроит их в очередь к ресурсам одного процессора сервера вне зависимости от того, сколько еще процессоров на сервере спят.
Немногопользовательскость или «хайлоад? не, не слышал». Не смотря на то, что само по себе хранилище – это средство командной разработки, сервер хранилища не является таким средством. Это не более, чем средство сокрытия физического местарасположения файла 1cv8ddb.1CD от пользователей. Если имеется несколько раных хранилищ и количество разработчиков больше 10, то для нормальной работы на каждое хранилище нужна отдельная своя служба crserver. Потому, что служба ограничивается вычислительными ресурсами одного процессора и еще почему-то, что забито костылями в код этой службы – практический опыт автора статьи перевода некольких хранилищ со 100+ пользователей всего и 30+ параллельных на серверный вариант показал падение производительности на тех хранилищах, которые до этого перевода ни когда не тормозили потому, что маленькие (1cv8ddb.1CD до 500МБ). Потому, что пользователи даже маленьких хранилищ выстраиваются в одну общую очередь к одному процессору в скудном количестве потоков (task manager показывает чудовищное несоответствеи количества живых коннектов к crserver.exe и количества потоков, созданных процессом – на 23 коннекта было создано 7 потоков в ходе наблюдений в боевых условиях, проведенных автором статьи)
Выводы
На пратформе 8.2 служба crserver в виду своей однопроцессорности и эдакой «немного поточности» не является средством коллективной разработки. Она является средством предоставления доступа к хранилищу по набору абстрактных tcp-портов, чтобы не давать доступа клиентам ни к ftp, ни к cifs или smb (вот тебе, удаленный Вася, 32 tcp-порта, развлекайся на все деньги). Для больших команд не имеет смысла использовать серверное хранилище ни зачем, кроме как для предоставления ограниченного доступа удаленным разработчикам. Хотя последние разведданные недвусмысленно иллюстрируют, что лучше об этом даже не думать.
Однако в 8.3 crserver внезапно стал многопроцессорным. Достоверной информацией, с которого именно релиза началось многопроцессорное счасчастье, автор статьи не располагает - поиск в changelog'ах на эту тему результатов не дал но достверно известно и подтверждено экспериментально, что уже на 8.3.4.408 crserver грузит все процессоры, какие есть в системе.
- Последние изменения: 09.09.2014 21:20
- — Лефмихалыч
За исключением случаев, когда указано иное, содержимое этой вики предоставляется на условиях следующей лицензии: CC Attribution-Share Alike 3.0 Unported
При работе с хранилищем конфигурации время от времени могут возникать ошибки, предупреждения, которые не всегда являются критичными, и легко устраняются. Но зачастую разработчики, особенно новые, с ошибками не знакомы, или путаются в них, поэтому решено было собрать все ошибки и способы их решения в одном месте.
Речь пойдет о файловом варианте работы с хранилищем.
1. Ошибка аутентификации в хранилище конфигурации
Самая понятная из возможных ошибок. Данная ошибка возникает при вводе неверного логина и пароля.
Изменить логин и пароль может пользователь с административными правами на вкладке "Пользователи" окна "Администрирование хранилища конфигурации"
2. Пользователь существующей связи отличается от текущего
Тут важно понимать принцип работы хранилища конфигурации. Хранилище используются для коллективной разработки, т.е. у каждого разработчика есть своя база для разработки, есть свой пользователь хранилища, и все под своими логинами подключаются в свои базы. На практике бывает, что существуют общие базы, например на сервере для тестирования, и если она подключается к хранилищу, для нее необходимо заводить также отдельный логин и заходить в нее под ним (для удобства, в качество логина общей серверной базы можно использовать имя самой базы). Девиз хранилища: на каждую базу свой логин в хранилище.
Данная ошибка возникает, когда текущая база уже подключена к хранилищу под каким-то логином, а вы пытаетесь ввести другой логин. Это может быть по разным причинам:
- вы зашли в общую базу и пытаетесь войти под своим логином хранилища. Необходимо выяснить логин этой конкретной базы, и заходить под ним, но не переподключать под своим. Посмотреть, под каким логином подключена каждая база может пользователь с административными правами в хранилище, на вкладке "Подключения" окна "Администрирование хранилища конфигурации"
- вы развернули базу, которая уже была подключена к хранилищу. Необходимо отключить конфигурацию от хранилища и подключить заново.
3. Пользователь уже аутентифицирован в хранилище
Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. И с ней работают под этим логином в данный момент.
При такой ошибке вы не сможете подключиться под введенным логином. Необходимо подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.
4. Для данного пользователя уже имеется конфигурация связанная с данным хранилищем конфигурации
Предупреждение похоже на ошибку из предыдущего пункта, но есть небольшое отличие.
Данная ошибка возникает, когда любая другая база уже подключена к хранилищу под логином, который вы вводите в текущей базе. Но с ней не работают под этим логином в данный момент.
Предупреждение позволяет подключиться под введенным логином, но нужно понимать последствия. Если вы подключитесь под эти логином, то у другого пользователя рано или поздно возникнет ошибка из предыдущего пункта или аналогичное предупреждение. Рекомендую подключиться в хранилище под другим логином, либо найти того, кто подключился в другой базе под этим логином и договориться о том, кто использует этот логин.
5. При получении данных из хранилища или захвате объекта: Не удалось зафиксировать таблицу для чтения "Versions"
Данная ошибка возникает, когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.
Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.
6. При подключении к хранилищу: Не удалось зафиксировать таблицу для чтения "Users"
Данная ошибка может возникать:
- когда вы уже длительное время подключены к хранилищу и за период работы были разрывы соединения.
Чтобы избавиться от ошибки, необходимо закрыть конфигуратор и зайти заново.
- когда в этот самый момент другой пользователь помещает большой объем данных в хранилище
Необходимо подождать, пока другой пользователь закончит помещение объектов в хранилище.
7. Файл не является файлом базы данных
Ошибка соединения с хранилищем конфигурации по адресу:
\\Server\Repository\project1
по причине:
Файл не является файлом базы данных '//Server/Repository/project1/1cv8ddb.1CD'
Данная ошибка может возникать при подключении к хранилищу:
- если есть зависший фоновый процесс к этой базе.
Необходимо зайти в диспетчер задач и принудительно снять зависший фоновый процесс, после этого повторно попробовать подключиться к хранилищу. Если база серверная, то этот процесс может быть зависшим у кого-то, кто работал с базой ранее. Необходимо найти, кто последний работал и попросить почистить у себя в диспетчере зависший процесс.
- если есть зависший сеанс другой базы, подключенной к этому хранилищу на этом компьютере
Так бывает, что одновременно приходится работать с разными базами в одном хранилище. Если про одну базу надолго забыть, и в ней будет появляться ошибка №5, то другую базу с этим хранилищем вы открыть не сможете. Необходимо завершить "забытые" сеансы.
8. Файл базы данных поврежден.
Ошибка соединения с хранилищем конфигурации по адресу:
\\Server\Repository\project1
по причине:
Файл базы данных поврежден '\\Server\Repository\project1\//1cv8ddb.1CD'
Данная ошибка может возникать:
- когда разработчики, подключенные к одному хранилищу, работают на разных версиях платформы и один из них поместил что-то из новой версии платформы.
- когда файл базы данных был действительно поврежден (отключение электричества, скачки напряжения и т.п.)
1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу
2. Почистить кэш хранилища
3. Одному запустить конфигуратор от имени администратора
4. Подключиться к хранилищу
Если указанные действия не помогли, можно воспользоваться утилитой chdbfl.exe, но в моей памяти мне она ни разу не помогла и единственным выходом было создание хранилища с нуля.
9. Неклассифицированная ошибка работы с хранилищем конфигурации
Данная ошибка может возникать, когда к хранилищу подключаются разными версиями платформы. Например: 8.3.10.2667 и 8.3.12.1529
1. Всем разработчикам закрыть все конфигураторы, подключенные к хранилищу
2. Очистить глобальный кэш хранилища
3. Синхронизировать версии платформ.
10. Ошибка "База данных не открыта"
Данная ошибка может возникать при подключении к хранилищу:
- если есть зависший фоновый процесс к этой базе;
- если есть зависшие блокировочные файлы в каталоге хранилища.
1. Если причина в зависших фоновых процессах на локальном компьютере, то лечение как в п.7.
2. Если п.7 не помог, то необходимо всем закрыть конфигураторы, зайти в каталог хранилища, и удалить блокировочные файлы размером 0 байт.
11. Ошибка "Ошибка совместного доступа к хранилищу конфигурации"
При получении данных из хранилища возникает ошибка:
---- Начало операции с хранилищем конфигурации ----
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Повтор попытки получения объектов из хранилища конфигурации
Ошибка совместного доступа к хранилищу конфигурации:
\\Server\Repository\project1
Не удалось заблокировать таблицу 'OBJECTS'
---- Операция с хранилищем конфигурации отменена ----
Данная ошибка может возникать при получении данных из хранилища:
- если в этот момент с другого компьютера запущен процесс оптимизации хранилища;
1. Дождаться окончания оптимизации хранилища
2. Повторно запросить получение данных из хранилища.
Это, конечно, не весь список ошибок, который может возникать при работе с хранилищем. Я привёл те ошибки, с которыми я лично не раз сталкивался и решал указанными мной способами. Если у вас есть ошибка, которая не описана, и вы знаете способ ее решения, пишите в комментарий, я с удовольствием добавлю информацию в общую статью.
Читайте также: