суббота, 28 июня 2014 г.

Опять потеряли обновление

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



Запись блокируется для изменения другим "Каталогизатором" (особенности см. в выше упомянутом посте).



Но изменение может совершить "Абонемент". Он меняет состояние записи при выдаче, возврате, заказе и т.д..
Выдаём экземпляр произвольному пользователю.


Теперь, чтобы прочитать состояние экземпляра откроем ещё один "Каталогизатор".



Видим, что экземпляр выдан. Теперь сохраним запись в первом "Каталогизаторе" и обновим во втором.



Свершилось чудо! Выданный экземпляр стал свободным! Попробуем выдать его ещё кому либо. И у нас это получается



Это происходит по той причине, что "Абонемент" не проверяет блокировку. А "Каталогизатор", впоследствии, просто "кладёт" модифицированную запись поверх записи, модифицированной "Абонементом" ("потеря обновления").
Конечно, вероятность такого стечения обстоятельств невелико. Но она растёт на востребованных и свежих изданиях. Кроме того если что-то может случиться, оно обязательно ...
К сожалению, эту "нескладуху" "скрипт проверки БД" (см. справа) отлавливает (пока) не полностью. Если экземпляр ошибочно выдан второй раз он этого не покажет. Но до этого всё в порядке.



Видео по теме (лучше скачать 8.5 Мб)
Пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru

суббота, 24 мая 2014 г.

Кто книгу заказал?

Недавно обнаружилась одна особенность в поведении АС-Библиотека-3, при попытке заказа издания. Если пользователь не регистрируется в браузере, то заказ оформляется не на него, а на учетную запись, с которой WWW-Шлюз обращается к базе.
Не критично, но довольно неприятно. Издание блокируется и приходится периодически отменять заказы. В базе появляются мусорные записи, которые непригодны даже для статистики (нет информации о заказчике). Кроме того, если заказчик добросовестный, то процедура выдачи значительно усложняется. Дело в том, что правильно заказанное издание сразу появляется на вкладке "Выдача", модуля "Абонемент". И остаётся лишь нажать кнопку "Выдать издание читателю". В противном случае необходимо вначале отменить заказ с учётной записи доступа к базе, а потом пройти всю процедуру, начиная с поиска. Поэтому этот случай действительно "противный".
Справиться с этой проблемой довольно просто. Нужно создать фиктивную учётную запись пользователя, с которой WWW-Шлюз будет "доступаться" к базе. Причём держать её в "неперерегистрированном" (ужас) состоянии.
Смотрим конкретно. Открываем браузер, находим произвольное издание и заказываем его без регистрации.



Видим, что издание успешно заказано. Чтобы определить на кого, откроем в "Администратор" таблицу All__Delivery.



Поле ReaderID соответствует Администратору. Открываем "Абонемент", ищем Администратора и на вкладке "Выдача" находим заказанное издание.



Настройка шлюза (по умолчанию).



(Для тех, кто интересуется безопасностью напомню, что настройки шлюза хранятся в файле EWww.xml, доступном из Интернет по умолчанию. См. пост "Шлюз" в архиве.)
Теперь, как исправить. Отменим предыдущий заказ. Создадим фиктивного читателя.



Учётные данные произвольны, только даты общей регистрации как можно раньше, чтобы пользователь не попал в статистику. Далее, логин и пароль заносим в настройки WWW-Шлюза.



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



Теперь регистрируемся. Всё в порядке.



Смотрим заказ в модуле "Абонемент".



Криво. Но это всё, что можно сделать своими руками.

И, раз уж мы здесь, хочу отметить один момент. В версии 3.3.43 была такая неприятность - если заказан конкретный экземпляр, то выдать можно только его. То есть с полки надо было взять именно этот экземпляр (инвентарный номер, штрих код ...). Или переоформлять как смотри выше. Из-за этого, вся система заказа была принята в штыки (в таком состоянии, увы, находится и сейчас). В версии 3.3.58 появился выбор "Зарезервированные" или "Все доступные".



Теперь можно выдать любой свободный экземпляр.
Система заказа мощный инструмент, но, к сожалению, им мало кто пользуется. Согласись, переться через весь город, зная, что книга есть, и экземпляр забронирован тобой, гораздо приятней.
Добавил видео в посты "Транзакции" и "UAC нам в помощь" (см. архив)
Пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru

суббота, 17 мая 2014 г.

А что у нас с индексами?


Работать с БД и не затронуть тему индексов невозможно. Однако она настолько обширна, что одним постом её не покрыть. Здесь лишь определимся с терминологией и рассмотрим общее положение дел.
Что мы знаем про индексы? Они ускоряют поиск данных и занимают дополнительное пространство в базе. Если первое видно сразу, то со вторым несколько сложнее.
В  "АС-Библиотека-3", некоторые обычные таблицы (например, Demo_01003 Demo_01003X) также выполняют роль индексов. Будем называть их программными индексами, а обычные - системными. Поскольку программные индексы это обычные таблицы, они, в свою очередь, проиндексированы системными. Так называемые "док" индексы (в терминологии АС-Библиотека-3) содержат данные 090 полей, поэтому это не совсем индексы.
Какова ситуация с индексами в "АС-Библиотека-3"? В случае с SQL, процедура с незатейливым названием sp_spaceused отвечает на этот вопрос:

EXEC sp_spaceused @updateusage = N'TRUE';

Вот скриншот с рабочей базы


Если перевести в проценты, то 33% занимают данные, 66% - индексы и чуть больше 1% свободно. То есть, на каждый байт информации приходится два байта информации о её размещении! Естественно sp_spaceused "замеряет" только системные индексы, так как программные, для неё, это обычные таблицы. Если база небольшая то проблемы нет, а если за гигабайт, то с этим надо что-то  делать.
В случае с базой "Access" подобный запрос мне неизвестен. Однако можно поступить следующим образом. Сжать базу. Сделать копию. И, тупо, поудалять все индексы из копии. Сжать её и сравнить размер с исходным. У меня получилось сокращение на 57%. Результат близкий, хотя не все системные индексы были удалены, а только наиболее "ёмкие". А также удалены все программные (так было проще - с каждым программным индексом удаляется как минимум два системных). Кроме того, очевидно, что в Access и SQL системные индексы организованы по-разному. Если надумаешь поэкспериментировать самостоятельно, вместо Access рекомендую пользоваться менеджером БД вроде DATABASE.NET (http://fishcodelib.com/Database.htm). Кстати он и сжимать умеет.
Почему всё так? Дело в том, что изначально, в АС-3, на всякий случай, проиндексировано ВСЁ! И возиться с индексами ("затачивать") придётся тебе (если ты админ). Так обстоят дела в любой относительно сложной системе на основе СУБД. К сожалению одной "волшебной кнопки" здесь нет. Слишком сильно всё завязано на условия эксплуатации. Хорошая новость в том, что работа с программными индексами в АС-Библиотека-3 организована весьма неплохо. А про системные и говорить нечего. Главное помнить, что индексы это не информация. Это информация о размещении информации. Поэтому они возобновимы после удаления. Создавая и удаляя индексы, мы можем ускорить работу и увеличить размер базы при этом, и наоборот. Главный вопрос состоит в том, какие индексы использует АС-3 в работе, а какие являются балластом.
В SQL базах, система индексирования гораздо более развитая по сравнению с Access и возможностей по анализу и настройке больше.

И в конце. У меня нет никакой информации о том, чтобы кто-то использовал скрипт проверки БД (см. пост выше). Поэтому он не развивается. Всё зависит от твоей активности.

Пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru

четверг, 23 января 2014 г.

UAC нам в помощь

Начало года. Поэтому, для разгона, что-то простое.
Время идёт. "Хрюша стареет" и постепенно становится историей. Новые "оси" каким-то образом проникают в хозяйство. Всё бы ничего, но этот UAC ... А мы его хрясь и отключим! Но не торопись. "Кто нам мешает, тот нам поможет". И вот в чём.
Не является редкой ситуация, когда за одним компьютером закреплено несколько пользователей. При этом их требования  к настройке модулей может быть различной. Разная острота зрения требует разного размера шрифта. Разные пароли необходимо каждый раз вводить вручную (ищи пост в архиве "О вреде работы под Администратор 123"), вместо того, чтобы "запомнить". По-разному настроенные колонки, шаблоны. Да мало ли что ещё?
К сожалению АС-Библиотека-3 такой возможности не предоставляет, и настройки распространяются на всех пользователей сразу. Проблема заключается в том, что АС-3  хранит их в XML и INI файлах, лежащих в тех же каталогах что и сами модули, а не в профилях или ветках реестра, относящихся к текущему пользователю. С другой стороны UAC, любой модифицированный файл (из защищённой области) автоматически виртуализирует в профиле пользователя и будет прозрачно "подкладывать" вместо исходного. Понял в чём ФИШКА?
Тогда давай посмотрим, как всё это работает. Для начала создадим две учётки в ОС с "Обычным доступом" то есть с правами обычного пользователя "биб1" и "биб2".



Теперь создадим две учётки в АС-3 с правами "Библиотекарь", для простоты, с такими же логинами



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



и посмотрим, что произойдёт с файлами.



Появилась кнопка "Файлы совместимости". Жмём. Смотрим куда попали. У меня получилось

"C:\Users\биб1\AppData\Local\VirtualStore\Program Files (x86)\АС-Библиотека-3\ECatalog"
(в 32 разрядной ОС (x86) не будет; папка AppData скрытая)



Эти файлы ОС подсунет "Каталогизатору", когда его запустит пользователь "биб1".

Далее входим как "биб2". "Запомним" пароли для "биб2". Увеличим размер шрифта. Поменяем местами "Заглавие" и "Автор". И, просто сократим вывод на вкладке "Инвентарные номера".



Попробуем открыть в проводнике профиль "биб1". Доступа нет, что неплохо в плане безопасности.



Теперь опять войдём в ОС под "биб1" и увидим, что все его настройки сохранились!




Видео по теме. (Для просмотра лучше скачать)

Как всегда пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru.