Форумы GIS-Lab.info

Добрый день!
Помогите решить такую проблему. У меня есть многопользовательская БД на MS SQL Server. Данные я загружаю под одним пользователем, публикую сервисы на гис-сервере под другим. Изначально я выдала издателю права на чтение и изменение. Потом эти права отозвала.
Однако после публикации каждого сервиса этот издатель создает какое-то огромное количество блокировок, которые конфликтуют с владельцем данных и не дают вставлять данные в наборы классов объектов и регистрировать данные как версионные.
Выглядит это так Как это исправить? Что я делаю не так?

И теперь в связи со всей этой петрушкой мне выдается сообщение вот такого вида Что с этим делать, помогите!

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

wladfm писал(а):Для регистрации как версионного, удаления классов простарнственных объектов из базы нужен монопольный доступ к бд.

а это точно? я не могу найти в документации информации о том, как нужно организовывать регистрацию версионных данных или добавление новых классов объектов, если в БД работают несколько пользователей и при этом та же БД используется несколькими гис-серверами с опубликованными сервисами
Сообщение об ошибке подключения наверное потому что создается куча подключений от пользователя publisher с обоих гис-серверов. Только не могу понять, почему так происходит

amnesiac писал(а):Сообщение об ошибке подключения наверное потому что создается куча подключений от пользователя publisher с обоих гис-серверов. Только не могу понять, почему так происходит

Каждое подключение к гис-серверу создает блокировку либо группу блокировок (зависит от гис-сервера, используемых им ресурсов).
Для корректной работы с гис-сервером пользователю в ms sql server можно дать разрешения на создание функции, создание таблицы, создание процедуры, создание представления и соединение. Это те права, которые мне удобны и необходимы для работы.
Тогда добавление объектов в бд будет возможным, но не удаление, т.к. вначале необходимо от удаляемого ресурса отключить пользователей. Регистрация как версионного требует монопольный доступ к бд.

http://desktop.arcgis.com/ru/arcmap/10. ... sioned.htm

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

У меня такой еще вопрос - если я буду обновлять слои не путем удаления из набора классов объектов, а с использованием синхронизации с дочерней репликой БД (как я планирую настроить механизм обновления), нужно ли будет останавливать сервисы?

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

При репликации (если мы говорим о встроенном механизме ArcGIS) не нужно останавливать сервис, т.к. данные при ней должны быть версионными и там идет версионное редактирование. Не поклонник я если честно данной технологии. На уровне БД - это вопрос прав доступа.
Инструмент сортировка предполагает создание нового набора данных. Это происходит потому что меняется порядок записи данных в в наборе. Переименование на исходное имя дает замену текущего набора: вначале удаление, потом вставка. Поэтому блокировка бд не дает это осуществить.
Если вы хотите более качественно обновлять бд, лучше останавливать сервисы. Этот процесс можно автоматизировать.
Также есть вопрос о целесообразности обновлений. Если БД должна редактироваться на локальных БД и просто выкладываться на вашем геопортале, то проще использовать версионное редактирование. Есть более изващёренные методы (прим., на основе триггеров)

wladfm писал(а): Также есть вопрос о целесообразности обновлений. Если БД должна редактироваться на локальных БД и просто выкладываться на вашем геопортале, то проще использовать версионное редактирование. Есть более изващёренные методы (прим., на основе триггеров)

А что за извращенные методы, можно поподробнее?

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

Извращенные - это на уровне БД. Здесь всё зависит от того, что необходимо сделать, каждое задание по своему реализуется.