Пропадают пользователи при переносе базы (Орион 7.6.3)

FORUM_NAME: АРМ Орион
Описание: Программное обеспечение АРМ «Орион» предназначено для организации автоматизированных рабочих мест различного назначения при эксплуатации ИСО «Орион».
Справочная информация, руководства для АРМ Орион
Модератор: Модераторы
ogur4eg
Автор темы
ogur4eg
Автор темы
Репутация: 0
Сообщения: 3
Зарегистрирован: 12.03.2016
С нами: 8 месяцев 26 дней
Профессия: техник опс

Непрочитанное сообщение #1 ogur4eg » 12.03.2016, 15:20

Здравствуйте, форумчане, имеем порядка десятка объектов со СКУД на базе Орион (не Про). Народ постоянно туда-сюда мигрирует, въезжает-выезжает. Связи между объектами нет, нет интернета (госконтора, чего уж). Соответственно постоянные турне туда-сюда для программирования. Для упрощения жизни некоторое время назад скопировали все базы в кабинет, там пару раз в неделю программируем новых сотрудников/удаляем старых, далее скидываем базы на флеш (для каждого объекта своя база), едем по объектам, заливаем, делаем перезапись кодов ключей в приборы. Сначала удаляли старую базу, на её место клали новую, открывали АБД, считывали приборы, делали перезапись. Всё это хорошо работало, но пропадал журнал событий. Стали оставлять файлы pLogData* от старой базы, а остальные удалять и вставлять от измененной новой, всё вроде хорошо, логи остаются на месте, полёт нормальный пару месяцев, пока не столкнулись с глюком - на двух объектах с двумя разными базами всплыл косяк. Косяк одинаковый, сотрудники и ключи разные - если скопировать базу без файлов pLogData*, то при открытии АБД там нет человека, которого вот буквально на днях программировали, просто нету его в базе как будто и не было, соответственно пропуск у него не работает. Теперь беру файлы pLogData* с базы на флешке (в этих логах почти ничего нет, они из кабинета), заменяю те что писались "на местах", запускаю АБД и уже вижу товарища с запрограммированным ключем. Как такое вообще может быть, всегда считал что в pLogData хранятся только события. Запускал проверку БД, нет замечаний, нажал "вылечить", не помогло, пока не подкину pLogData - сотрудник не появляется в АБД. :zvez_ochki: Что можно предпринять?

Sia-Ori
Активный участник
Активный участник
Sia-Ori
Активный участник
Активный участник
Возраст: 46
Репутация: 2
Сообщения: 763
Зарегистрирован: 04.02.2012
С нами: 4 года 10 месяцев
Профессия: инженер СКУД
Откуда: Ростов на Дону

Непрочитанное сообщение #2 Sia-Ori » 12.03.2016, 19:00

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

pet-and M
Активный участник
Активный участник
pet-and M
Активный участник
Активный участник
Возраст: 37
Репутация: 21
Сообщения: 1674
Зарегистрирован: 11.11.2012
С нами: 4 года
Профессия: инженер
Откуда: Санкт-Петербург

Непрочитанное сообщение #3 pet-and » 12.03.2016, 23:18

Я чего-то заморочки вообще не оценил. Если все равно выезжать на место и чего-то делать, то за каким-таким спрашивается не поступить штатным способом внесения/удаления сотрудников?

ogur4eg
Автор темы
ogur4eg
Автор темы
Репутация: 0
Сообщения: 3
Зарегистрирован: 12.03.2016
С нами: 8 месяцев 26 дней
Профессия: техник опс

Непрочитанное сообщение #4 ogur4eg » 13.03.2016, 13:50

Заморочка первоначально была придумана для того, чтоб в недалеком будущем при подключении объектов к инету, не ходить туда вообще, а заливать через какой-нибудь радмин базу. С уровнями доступа тоже всё просто, там практически везде на объекте турникет и всё, доступ 24 часа в сутки, уровень доступа всем Максимум выдаётся (так исторически до меня делалось). Да и даже при таком раскладе как сейчас, уходит в сумме намного меньше времени на программирование и поездки, я этим пару лет занимался, задолбало.
Небольшое отступление: иногда есть надобность запрограммировать один пропуск на два объекта с разными считывателями, всё делается в кабинете и нет надобности посещать с этим ключем два далеких друг от друга объекта. На одном стоят считыватели Perco (по протоколу Wiegand) они дают код ключа отличный от того что даст считыватель Болид (по Touchmemory), соответственно если я программирую ключи на месте как делал раньше, мне с одним и тем же ключем надо и туда и сюда смотаться, я не могу скопировать его код в АБД и перенести в другую базу, ибо код этот отличается.
Да дело-то не в процедуре, посудите сами - у Вас база на объекте, Вы можете добавлять и удалять сотрудников там, а можете скопировать её, перетащить на свой рабочий компьютер, добавить/удалить сотрудников, добавить ключи, и притащить обратно. Всё это реально работает, на объекте только считываю конфиги приборов, коды ключей и делаю перезапись (чтоб СКУД работала и в случае умирания компа). Работает даже если НЕ перезаписывать файлы pLogData которые на объекте ведутся на месте (чтоб сохранялся адекватный лог). В этой системе я не сомневался, уверенный на 146% что в pLogData* хранятся ТОЛЬКО логи. Однако буквально на днях я словил такой косяк, который описывал - оставляя на месте pLogData* объекта у меня не отображается в админке один товарищ, а на другом объекте в такой же ситуации - ещё один товарищ. Если закину pLogData* которые лежат с базой на флешке (которые когда-то давно велись на объекте, а потом стали вестись у меня в кабинете), то товарищ появится в списке сотрудников в админке, со своим ключем.Как такое вообще может быть, ума не приложу :(

Sia-Ori
Активный участник
Активный участник
Sia-Ori
Активный участник
Активный участник
Возраст: 46
Репутация: 2
Сообщения: 763
Зарегистрирован: 04.02.2012
С нами: 4 года 10 месяцев
Профессия: инженер СКУД
Откуда: Ростов на Дону

Непрочитанное сообщение #5 Sia-Ori » 13.03.2016, 15:27

Глюки описанные могут быть на семёрке, что то там было такое с версиями файлов, ну да ладно.
Уровни доступа одни и те же, это упрощает дело.
два кода ключа - ну и что... Можно из одного кода получать два, скорее всего. Можно записывать в базу сразу два кода.
Можете примеры кодов написать с Перко и с ХХХ, что там у вас второе.
Вам надо обеспечить согласованность ID пользователей и ключей по разным базам, а проще всего это сделать через мастер-базу, удаляя из неё лишнее. В центре ведёте полный список пользователей с ключами, с двумя версиями ключей, на периферию рассылаете обрезки мастер-базы.

ogur4eg
Автор темы
ogur4eg
Автор темы
Репутация: 0
Сообщения: 3
Зарегистрирован: 12.03.2016
С нами: 8 месяцев 26 дней
Профессия: техник опс

Непрочитанное сообщение #6 ogur4eg » 13.03.2016, 23:15

На компьютерах везде стоит ХР, 7ка только на одном объекте, с ним проблем не наблюдал, хотя там и уровни доступа разные и окна времени есть, в отличие от остальных.
Код ключа через считыватель Болид по протоколу Touchmemory
37002801BCBBD201
Код этого же ключа но через считыватель Perco по протоколу Wiegand
2B000000BCBBD201
Как видите, отличается первая половина ключа. Но это всё равно, в кабинете есть и болидовский и перковский считыватель, это меня не особо беспокоит.
А вот про мастер-базу интересно, это реализуемо в Орионе? Что из себя представляет и как мне потом делать обрезки с одной общей базы? И самый интересующий вопрос - как сделать мастер-базу из существующих десятка баз с количеством человек в каждой от 100 до 1500?

Sia-Ori
Активный участник
Активный участник
Sia-Ori
Активный участник
Активный участник
Возраст: 46
Репутация: 2
Сообщения: 763
Зарегистрирован: 04.02.2012
С нами: 4 года 10 месяцев
Профессия: инженер СКУД
Откуда: Ростов на Дону

Непрочитанное сообщение #7 Sia-Ori » 14.03.2016, 19:04

А мастер-базе у вас должны быть все сотрудники со всех филиалов, на каждого по две карты. как-то надо помечать филиал. Вероятно, могут быть сотрудники, посещающие сразу несколько филиалов. В некое текстовое поле в АБД вписывать 0 - для уволенных, 100 - для посещающих всё или номер филиала - для остальных.
При подготовке БД (а точнее пары pMark + pList) для конкретного филиала удалять всё лишнее парой запросов, если с SQLем у вас туго попозжа могу проверить эти запросы.
Слитие - процесс тоже реализуемый средствами SQL.


  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «АРМ Орион»

Кто сейчас на форуме (по активности за 5 минут)

Сейчас этот раздел просматривают: 3 гостя

forum-bolid.ru : Отказ от ответственности