Коллеги, всем привет. У нас ведется совместная разработка, так что активно пользуемся хранилищем конфигурации. В связи с этим, время от времени, приходится обновлять базы, которые подключены к хранилищу. И после обновления,конечно, приходится переподключаться. А это дофига долго. И вот тут у меня возник вопрос: Есть ли у кого нибудь описание файлов хранилища? Ибо подозреваю, что где-то нужно просто обновить гуид базы, или что-то подобное, а не переподключаться каждый раз к хранилищу, что занимает, как правило у нас, около пары часов...
Спасибо!

Хранилка - женский род, используется как сокращение для понятия "хранимая процедура СУБД"

(1) ХраниМка, пардоньте.
Хранилка - это баба какая-то... Тип брата-келаря...

(0) Иш чего захотел... Может тебе ещё исходные коды платформы дать?

(2) Нам, провинциалам, вас, интеллигентов, не понять

(1), (2) - это ценная информация, спасибо, коллеги, учту!

(0) переподключайся.... иначе будут проб леммы, проверенно...

ну а формат схож с 1сд, описание я видел на инфостарте

(6) ну а какие проблемы? Нарушение синхронизации? В рабочей базе ничего не захвачено никогда. Перед обновлением ИБ я тоже все объекты отпускаю. Единственный момент, если связь с хранилкой идет во множестве мест в базе, то да,тогда я рискую захватив в своей базе объект нарушить связанность базы ИБ хранилки...
но видать да,придется переподключаться. У нас особого доступа к sql нет, так что никто нас не пустит ничего трогать в sql базах. Даже в своих,которые для разработки...

"И после обновления,конечно, приходится переподключаться" не понял почему "конечно"

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

Далее только личное мнение, основанное на личном и чужом опыте:
Лезть в кишки таких конструкций, это гораздо дороже. Прям капец как дороже. В итоге всё равно придёте к нормальной схеме реализации. Проверено на многих конторах.
Что бы не материться от подключения к хранилищу, рекомендуется просто юзать 2 тестовых базы. В одной базе работаешь, другая долго подключается, потом всё меняется местами. Я ещё и третью использую, которая перед последним обновлением лежит наготове.

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

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

(11) >> я, правда, не уверен, даст ли это ускорение
Не даст. Пробовали уже.

(12) Спасибо за инфу. Хоть не медленнее, уже хорошо. Поднимают-то в основном для надежности при удаленном подключении.

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

(14) Они переодически на разработческие базы тупо накатывают бэкапы из рабочей, в которых своя настройка подключения к хранилищу.

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

(16) Да хоть терабайты. Все равно окупается.

Эдакий персональный semi-staging

(16) А как тестировать на рабочих данных? У меня был один отчетик... На тестовой базе в 2Г работал 15 сек.
В рабочей (на 3Т) - в зависимости от настроек - от тех же 15 сек до 10 минут.
И повторить на тестовой не удавалось. Пока не взял актуальную рабочую - причину не нашёл. А как взял - за полчаса вся проблема решилась

(13) Падения? Я использую хранилища по полной. Прям вот даже когда только один разрабатываю. При чём хранилища использую так, что серевера блеять начинают. Так вот падения были только когда на диске с хранилищем место кончилось.

(19) Малоопытные программисты в рабочих тестируют и тут же правят(((((((

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

(21) Спасибо за комплимент ))

(16) >> там сотни ГБ данных
Стоимость дисков под базы во много раз меньше стоимости недоразработок, косяков и просто технического долга

(16) Базы подключенные к хранилищам все равно необходимо обновлять время от времени при активной разработке. Иначе аналитику негде будет построить тестовый пример, на основе которого аналитик напишет заказчику информационное письмо с блэкджеком и картинками. В этом смысле все верно говорит (17).
(22) у нас для этого есть ежедневные копии, которые, естественно, не подключены к хранилищу. Почти рабочая, тока без регламентных заданий и юзеров)

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

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

(26) Нет-нет, уверяю, никакого сервера хранилища. Тормозит, даёт сбои, зависает, в общем что угодно, но не падения. При этом ставим сервер хранилища и все тормоза, сбои и зависания точно такие же. Может мне так везёт, но повторюсь - использую хранилище прям по полной, не ограничивая себя ни в чём.

(28) Ну а я с десяток раз сталкивался с крахом базы хранилища. Большая часть приходилась на попытки работать с ним через VPN.

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

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

(28) Я использую хранилище через сервер как в локальной сети, так и в удаленной, если еще один клиент, у которого через шару. Через шару все очень медленно и периодически глючит, через сервер - вообще не было никаких проблем.

Ну или EDT вам в помощь, почувствуйте всю прелесть.

(30) не получится по причине (26)

(34) А в чем суть причины (26)? Это же источник потенциальных проблем и текущих неудобств. Типа таким образом параллельно тестите новые релизы?

(35) сервер хранилища не работает с разными версиями платформы. Или 1совцы уже научили его?

(36) Мой вопрос был о том, по какой причине разработка ведется на платформах, новее продакшена.

(37) ну где-то надо тестировать рабочую платформу. При том зоопарке баз , что у нас есть, накатывать свежую платформу вообще чревато, ибо некоторые базы используют режим совместимости. Вообще, новые конфы типа БП3, ЗУП3.1 требуют свежих платформ, а вот старые, типа УПП1.3 крайне критично к ним относятся. Недавно был гюк с немодальными окнами в режиме обычного приложения в новой платформе. Пришлось срочным порядком переписывать всё на модальность... да мало ли что может быть...

(26) То есть вы разрабатываете на одной версии платформы, а в продакшне используете другую? Ну, удачи вам.

(39) то есть вы каждый раз при разработке используете обязательно все новые плюшки новой платформы? Ну, удачи вам.