Доброго.
Какая разница в стабильности/производительности в работе с храном между вариантами:
Второй вариант (все через сервер) - ок.
Остальные - отказать из-за риска поломки хранилища, например, если кто-то подключится с неправильной версией платформы.
2 правилен и единственный рабочий при нескольких разработчиках.
1 и 3 пробовали, не работает.
Будут постоянные проблемы с доступом разных пользователей.
Дело в том, что в 8.3 создаются отдельные файлы на элементы хранилища и этим файлам выдаются права от имени создателя, права от каталога хранилища почему-то не всегда выдаются.
В итоге один разраб помещает свои новые объекты в хранилище, у него коммит в хранилище проходит,
далее 2-й разраб захватывает эти новые объекты, меняет в 1С, но коммит не проходит,
т.к. выдается ошибка системы проо доступы.
При работе с хранилищем через сервер этих проблем, т.к. все изменения попадают от одного системного пользователя, под которым стартует сервер хранилища.
У нас работа ведется по варианту 3. Проблем замечено не было.
Сама 1С говорит, что без разницы как подключаться:
В общем случае система «1С:Предприятие» обеспечивает одновременную работу с хранилищем конфигурации с использованием всех протоколов доступа к хранилищу: файловый доступ, протокол TCP и протокол HTTP.
Но работа через сервер мне нравится идеей, что не надо постоянно дергать админов на добавления прав пользователю на шару.
Какие-то неленивые у вас админы - раз права устанавливают поименно.
Куда проще - назначил доступ на шаре группе пользователей, дал вам права на изменение группы, поставил оснастку AD. И больше не отвлекаешься на всякую ерунду. Максимум, изменить состав группы самостоятельно раз в полгода, когда отвественный 1С-ник в отпуске.
“Чистых” вариантов доступа всего 2:
Есть возможность организовать дополнительный транспорт через HTTP (еще 2 “серых” доступа):
3. HTTP с подключением к файлам
4. HTTP с подключением к серверу
Остальное - комбинации в том или ином виде этих четырех видов.
Затем начинаются ньюансы:
п. 1 есть возможность разграничить права доступа к хранилищам.
п. 2 обеспечивает максимальную согласованность доступа к хранилищам. С правами печаль - кто угодно может подключаться к серверу и создавать новые хранилища. Хорошо, что еще удалять хранилища через сервер нельзя.
п. 1 позволяет переместить уже неиспользуемое хранилище в архив
п. 2 сервер хранилища “держит” файлы. Убрать неиспользуемое хранилище можно только остановив сервер. Зато проще организовывать обслуживание хранилищ - достаточно остановить сервер.
п.1 дает возможность подключаться к хранищу с разными версиями платформы (естественно по очереди).
п.2 только одна версия платформы. разработка когда тестовый контур уже на новой платформе, а рабочий контур на старой возможна только с костылями.
a с gitsync как? ему же файловый доступ к храну нужен
Гитсинку доступ на чтение нужен, никаких проблем с ним не выявлено.
Юрий, а можно вопрос касаемо третьего пункта?
Пример конфигов подключения.
Хм, поднял по документации - такого варианта нет. Прошу прощения, что ввел в заблуждение. п.3 отменяется
Спасибо.
Эх, а счастье было так близко 