Дубликаты ключей/карт в приборах и БД

[Shuniander]

Здравствуйте!
В Администраторе БД существуют такие процедуры, как "Поиск дубликатов ключей в приборах" и "Поиск дубликатов ключей в Базе Данных". В инструкции хорошо расписано, как их находить (и от них же избавляться). Но каким образом они появляются, эти самые дубликаты ключей? Можно ли какими-либо действиями предотвратить их появление в БД и приборах?

[Sia-Ori]

Глюки программ, глюки приборов, глюки при передаче данных по сети.
Это всё вероятные причины. Какая из них главная - неизвестно. Но дубликаты для сколь нибудь крупного СКУДа на Болиде - это данность.

[Shuniander]

Глюки программ, глюки приборов, глюки при передаче данных по сети.
Это всё вероятные причины. Какая из них главная - неизвестно. Но дубликаты для сколь нибудь крупного СКУДа на Болиде - это данность.

Спасибо. То бишь, ежели я правильно понял, явление это - незапланированное, и где, когда и сколько дубликатов "родится" - этого мы никак не предугадаем, появляются они вне зависимости от нашего желания. Но периодически избавляться от них всё равно необходимо, как от ненужного балласта Базы данных?

[pet-and]

Я так полагаю, что дубликаты ключей появляются не столько из—за глюков, сколько от нетерпеливости пользователя, сразу не обновились ключи, надо ещё разок кнопку надавить, опять не так, ещё жиманем. Дубликаты в базе до сих пор замечены не были.

[Shuniander]

Я так полагаю, что дубликаты ключей появляются не столько из—за глюков, сколько от нетерпеливости пользователя, сразу не обновились ключи, надо ещё разок кнопку надавить, опять не так, ещё жиманем. Дубликаты в базе до сих пор замечены не были.

Спасибо, учтём-с...

[pet-and]

Это вопрос обслуживания базы данных. Периодически необходимо проводить "чистку": удаление лишних ключей, реиндексация, перезапись ключей в приборах, считка конфигураций приборов.
Не знаю с чем это связано, но при установке резервного копирования и реиндексации по расписанию, глюки в СКД множатся, хотя это все субъективно, может только у меня так.

[Sia-Ori]

Я так полагаю, что дубликаты ключей появляются не столько из—за глюков, сколько от нетерпеливости пользователя, сразу не обновились ключи, надо ещё разок кнопку надавить, опять не так, ещё жиманем. Дубликаты в базе до сих пор замечены не были.

Да ладно! в Орионе Про и давить то нечего, а дублей - полно. И не только дублей. Те карты, которые в контроллере когда-то были, потом им уровень доступа изменён, должны быть запрещены, ан нет. Работают.
И где жать - не пойму. Просветите.

[Sia-Ori]

при установке резервного копирования и реиндексации по расписанию

Не замечал никакой связи.

[AlexRuden]

На программном уровне в Орионе врядли есть ошибка с "появлением дубликатов" / "пропаданием ключей" . Скорее всего это происходит при обменах с контроллерами (синхронизация ключей) из-за некачественной связи (плохое качество передачи сигналов по RS485). Типо происходит рассинхронизация электрического представления протокола болида. Чем качественнее линия интерфейса, тем меньше глюков с ключами.
Есть другие мнения?

[pet-and]

Не замечал никакой связи.

Я не утверждаю, что есть прямая связь, однако мною такая усмотрена; отменил сии действия по расписанию и вот мне счастье, звонков стало гораздо меньше. Но тут можно еще свалить на нерадивых охранников, которые несколько бездумно тыркают по кнопкам при добавлении/удалении сотрудников и паролей.
А вот кстати вопрос, есть ли способ запретить удаление строк из таблицы базы данных, т.е. чтобы в строке сотрудника/пароля можно было поменять значение, а удалить строку нет?

Есть другие мнения?

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

[AlexRuden]

А вот кстати вопрос, есть ли способ запретить удаление строк из таблицы базы данных, т.е. чтобы в строке сотрудника/пароля можно было поменять значение, а удалить строку нет?

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

[pet-and]

В том-то и дело, что очень хочется быть единственным админом базы, а пользователь пусть творит, что хочет,но в пределах дозволенного. А так, как сейчас - эти ламеры (т.е. представители заказчика) страдают праноидальным синдромом, хотят ну прямо полнейший доступ ко всему, а сами раздают пароли "Владельца", "Администратора" и т.п. любому своему сотруднику, который не боится кнопочки на компе понажимать. А юзеры как в одном нетленном фильме: "Мои орлы газет не читают, книг в глаза не видели, ну откуда у них идеи?" Туда-же в топку следуют и все инструкции, хоть упишись.

[прораб]

Тут вопрос не технический, а организационный. Хочет заказчик "всем владети", его право. Но и ответственность его.

[pet-and]

Тут вопрос не технический, а организационный. Хочет заказчик "всем владети", его право. Но и ответственность его.

Вот как раз ответственность заказчик мастерски перекладывает на меня, ты обслуживаешь - таки у тебя и не пашет. Вот не получается у меня доказать, что это балбесы тамошние бедокурят, хоть тресни.
А было бы здорово - нарисовал заказчику кучу паролей, среди которых только один властелин кольца болидова, и запретил все ненужное никому, кроме тебя. КРАСОТИЩА.

[Sia-Ori]

На программном уровне в Орионе врядли есть ошибка с "появлением дубликатов" / "пропаданием ключей" . Скорее всего это происходит при обменах с контроллерами (синхронизация ключей) из-за некачественной связи (плохое качество передачи сигналов по RS485). Типо происходит рассинхронизация электрического представления протокола болида. Чем качественнее линия интерфейса, тем меньше глюков с ключами.
Есть другие мнения?

Плохая связь - да. Глюк контроллера - тоже. Масса дублей, упор в ограничение в 4000 ключей, замена контроллера - и нормализация ситуации.
Но Болид, очевидно, не контролирует в своём протоколе, соответствует ли отправленное по шине и то, что получил контроллер и записал себе в память.
Программные глюки не с дубликатами, а с фантомами - есть.

[прораб]

Это у Вас договор составлен в пользу заказчика, а Ваша сторона, либо мышей не ловит в юридическом плане, либо прогибается под заказчика. Вам такой объект с геморроями так уж жизненно нужен? Мне нет.
Не знаю, как в Питере, а меня заказчики просто умоляют о заключении договора обслуживания СКД на Орионе.

[pet-and]

На самом деле мытьем да катаньем все уже устаканилось, но на будущее, чтобы не мучиться, хотелось бы сразу, сходу отрезать заказчику ненужные возможности. А вот вопрос нужности объекта не мой.

[AlexRuden]

На самом деле мытьем да катаньем все уже устаканилось, но на будущее, чтобы не мучиться, хотелось бы сразу, сходу отрезать заказчику ненужные возможности. А вот вопрос нужности объекта не мой.

Настраивайте разные учетки - СУБД под админом, Орион - под юзером.
Запрещайте юзеру все, что не положено (управление СУБД, реестр, игры, флешки, сд-приводы и т.д.)
СУБД должен обслуживать знающий ИТ-шник.

Но Болид, очевидно, не контролирует в своём протоколе, соответствует ли отправленное по шине и то, что получил контроллер и записал себе в память.
Программные глюки не с дубликатами, а с фантомами - есть.

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

[Sia-Ori]

1. Программные глюки давно бы уже исправили.
2. В протоколе все контролируется - общение синхронное, "вопрос/ответ" (во всяком случае такие команды есть в протоколе, а используются или нет - вопрос другой).
3. Но есть проблеммка с так называемыми отражениями сигнала в рассогласованном интерфейсе (всё те-же хреновые провода) - команды могут поступать более одного раза. Вот отсюда и вероятность возникновения дубликатов.

1. Ваша вера в Болид поражает.
3. Чисто технически - такое невозможно. Время распространения сигнала в проводе - порядка 0,2..0,3 скорости света. Смазать фронт одному биту - легко. Переотразить байт, это 10 битов, 1 миллисекунда - уже нужны расстояния порядка сотен километров. Ну а весь пакет, десятки байт - и того больше
2. Повторяюсь, не потрошил протокол. В ряде систем в ответ на пакет приходит от контроллера даже не просто квитанция, 07-й принял, а CRC посылки. Где-то контрольная сумма встроена в пакет. Болидовский протокол - дайте ссылку, посмотреть.
Сами контроллеры ещё сделаны весьма экономично. Медленная память, что там программеры наваяли - неведомо. Но, если софт в контроллерах такого же качества, как и софт для больших компов - глюки будут.

[MadHacker]

Это была в основном программная ошибка. Начали исправлять её ещё в sp5. В 1.12 долечили.
С версии 1.12 должна корректно работать синхронизация ключей и это не должно приводить к появлению дубликатов и фантомов даже при нестабильной связи с приборами.

Так что тем кто перешёл на 1.12 стоит один раз сделать перезапись ключей (если были или возможны какие то косяки) и дальше спокойно использовать синхронизацию.