суббота, 12 сентября 2015 г.

Время

В посте "Статистика без "Статистика"" я упоминал об одном "пеньке" и обещал отдельную тему. Для начала настоятельно рекомендую прочитать статью "Григорианский календарь" на Википедии или другом ресурсе. Проблема (в том числе и 2000) не в самом времени, а в его учёте, обозначении и многочисленных форматах хранения. В АС-Библиотека-3 внутренний формат хранения даты "Офисный". Иными словами это число с плавающей точкой. Целая часть - кол-во дней с 01.01.1900. А дробная - часть дня.
В строках Марк записей даты представлены различными форматами времени в виде обычных символьных строк и здесь мы их не рассматриваем.
Сразу после перехода на MS SQL обнаружилась одна проблема - при SQL запросе происходит сдвиг ровно на двое суток. Конкретно - преобразование числа, представляющего дату, в дату получаем дату на двое суток больше, чем должно представлять число. При этом никаких проблем в работе модулей не возникало. Всё работало корректно.
Вот пример.



Здесь ячейка слева в формате даты, а справа - в формате числа. Правая ячейка равна левой. Преобразуем это число в дату SQL запросом в Access (воспользуемся "Администратором").



Дата совпадает - 28 августа. Теперь в MS SQL.



Теперь число 42244 - это 30 августа! Почему? Ведь обе системы ведут отсчёт от 01.01.1900. Сразу оговорюсь, что совпадать они не обязаны, поскольку MS SQL не "Офис". Одни сутки находим сразу из документации. Оказывается, что Access ведёт отсчёт, начиная от 1, а MS SQL от 0. А где ещё одни сутки? Похоже проблема с учётом "супервисокосных" лет. Так и есть.


Смотри строку три, дата 29.02.1900. Но такой даты в истории нет! В этом можно убедиться, если "отмотать" системный календарь.


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

В логической базе пользователей User, для хранения времени, вместо типа вещественное число, почему то используется тип строка, которая является числом. Может потребоваться дополнительное преобразование. В скриптах статистики используется следующая конструкция

IF GetOptionValue( "Provider" ) = "1" THEN
'Access
    Val = " VAL( "
ELSE
    Val = " Convert( INT, "
ENDIF

Следующий 2016 год, как известно високосный. И ровно 29 февраля, при попытке вывести статистику "Распределение читателей" или "Регистрация читателей", появится следующая ошибка


Я просто изменил системную дату для демонстрации. Ошибка происходит во встроенной функции AgeToBirthDate(). У меня есть сомнения насчёт её корректности. Но это ты можешь проверить сам. Выход - вывести статистику на следующий день.

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

суббота, 6 июня 2015 г.

Штрих-код

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


Но, вместо штрих-кода - обычные символы. В чём же дело? Если в Ворде активировать меню "Разработчик" и открыть свойства поля, то увидим следующую картину.


Имя элемента F_010a является производным от Марк36 поля "010а", обозначающего штрих-код. А шрифт имеет весьма замысловатое название и явно не системный. Откроем папку "C:\Windows\Fonts" - такого шрифта здесь нет. Очевидно, система предложила замену. Но на самом деле он есть! Если прочитать тот же каталог в консоли, то увидим файл (в консоли отображаются имена файлов шрифтов, а не имена самих шрифтов).


Здесь команда dir дополнена строкой *39*, которая ограничивает вывод файлами, содержащими в имени 39. Получили список из одного файла, который нам и нужен. Здесь же набираем его имя и жмём ENTER. Открывается окно просмотра шрифта.


Нажимаем кнопку "Установить". Теперь повторно выводим читательский билет.


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


Что же это за загадочное число 39? Это просто часть обозначения стандарта кодирования "Code 39". Если наберёшь его в Википедии - получишь всю информацию. Я лишь отмечу свойство, позволяющее реализовать его в виде шрифта. Что это нам даёт? Ну, например вот:


Или вот



Как я это сделал? Просто выбрал нужный шрифт (который мы только что установили:). А как тебе вот это?


Здесь немного сложнее. Нужно соорудить небольшой скрипт, например такой:

DIM i
SetCardSize(60, 120)
SetBlock( 1, 0, 0)
FOR i = 1 TO FieldsGetCount(899)
Print(GetFieldEx( 899, i, "p", 1 ), 0, 0 )
NEXT
NextPage()

Этот скрипт выводит на карточку символы штрих-кодов экземпляров. Его необходимо сохранить в файл с любым именем (например "Штрихкод") и расширением ".crd", и поместить его в папку "ECatalog". После чего задать для карточки нужный шрифт. Заметь, что звёздочки здесь хранятся в базе. При большом размере шрифта, досадным образом, проявляется начальный перенос строки. Он присутствует на всех карточках. Его можно "убить" с клавиатуры и это, пока, единственный известный мне способ.
Возможно печать единичного штрих-кода в "Каталогизаторе" имеет спортивный или вспомогательный интерес. Вообще, есть два подхода - сначала печатаем, потом присваиваем или сначала присваиваем, потом печатаем. Возможна и комбинация этих методов. Здесь важно соблюсти уникальность, там, где это необходимо. Поле штрих-кода, как и инвентарный номер, в АС-3 с настройками по умолчанию, на уникальность не проверяется.
Вообще, для применения штрих-кода, в АС-3 можно найти немало мест. Это и есть то, что называется громким словом АВТОМАТИЗАЦИЯ.
И ещё несколько моментов относительно Code 39. Звёздочки в начале и в конце последовательности обязательны, но, в зависимости от настроек, сканер может выдавать их, а может пропускать. Кроме того, последний символ последовательности может быть контрольным и также выдаваться или пропускаться. Это так же зависит от настроек. Контрольный символ повышает надёжность считывания, но добавляет изрядных хлопот. Настройка сканера, как правило, заключается в считывании последовательности специальных настроечных штрих кодов, которые предварительно распечатываются из руководства и сложности не представляет. Однако менять настройки по ходу работы, очевидно, не получится. В базе, также можно хранить штрих-коды со звёздочками и контрольным символом, а можно без них. И генерировать скриптом при печати. Поэтому всю схему лучше продумать заранее.
В АРХИВЕ найдёшь файл под названием "FUNCTION_BarCode39.txt". Он содержит функцию, написанную на внутреннем скриптовом языке АС-3. Эта функция проверяет входную строку на допустимость в Code 39 и "заворачивает" строку звездочками. Если второй параметр = 1, то вычисляет контрольную сумму и добавляет в конец строки, согласно спецификации Code 39. Можешь использовать и модифицировать по своему усмотрению. Для применения нужно добавить её в конец (например) рабочего скрипта и вызвать в нужном месте. Если возникнут какие либо проблемы - сообщи.
Несколько слов о сканерах. Мне пришлось эксплуатировать сканеры, подключаемые в разрыв клавиатуры PS/2. В таком случае ни компьютер, ни ПО не различает, откуда пришли символы с клавиатуры или со сканера. В таком режиме эксплуатации каких-то настроек в АС-3 вообще не требуется. Сейчас USB сканеры, также могут эмулировать клавиатуру. На данный момент встречаются модели от 2 до 5 т.р. и, как правило, читают Code 39.
Чем и на чём печатать? Вопрос не тривиальный. Начиная от дорогих, специализированных, термопереносных принтеров штрих кода, до того, что есть под рукой. Для экспериментов достаточно последнего. Важны следующие параметры цена, стойкость и чёткость отпечатка, "размер уверенного считывания", удобство. "Самоклейка" здесь не помешает.
С другой стороны, почти половина продукции идёт с уже готовым штрих-кодом. Диски, журналы... Это, как правило, разновидности "EAN 13" (также ищи в Википедии). ISBN и ISSN являются его особыми случаями. Ничто не мешает использовать их вперемежку с другими типами кодирования. Единственное что хотелось бы отметить - не все сканеры читают (или настроены на чтение) дополнительных полей ISSN, идентифицирующих журнал с точностью до номера (EAN 2 и EAN 5). Это важный момент.
И, в конце, несколько слов о таком прогрессивном конкуренте, как RFID. Конечно, сказочная технология. Но, увы, пока только для "демонстративно дорогих" проектов. Без хорошего интегратора, с "ходовыми" испытаниями не менее полугода, здесь не обойтись. При этом нужно тщательно "следить за руками", иначе какая-то "мелочь" уронит все прелести. Я с подобными "мелочами" уже сталкивался. По крайней мере, пока расходники (метки) не станут торговаться с "открытыми" ценниками (нужно обращаться к менеджеру) - об этой технологии лучше забыть.
Пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru

суббота, 16 мая 2015 г.

Делаем статистику без "Статистики"

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

Начнём с простого. Вопрос - какая книга самая выдаваемая? Если отбросить все тонкости, можно свести к вопросу какая запись самая выдаваемая? Открываем "Администратор", переходим на вкладку "SQL". Пишем SQL запрос (Да, да, к сожалению, без SQL никак не обойтись. В крайнем случае, можно просто скопировать. И не забудь первое правило админа - сделать резервную копию:):

select top 10 SubDB, DocID, COUNT(DocID) as [Выдач] from All__Delivery
where BookState = 'Завершено'
group by SubDB, DocID
order by COUNT(DocID) desc

жмём "SQL Select" получаем результат.




Это первые 10 записей, с максимальной выдачей. Теперь достаточно открыть "Каталогизатор" и по имени логической базы (SubDB) и номеру записи (DocID) найти нужную запись.





Понятно, что этот запрос "разовый" - результат не изменится ни завтра, ни послезавтра. Поэтому в данном случае нет смысла что-то усложнять, хватит и "Администратора".

Однако таблицы скучны до безобразия. Добавим наглядной графики. Вспоминаем что база АС-3 - это база Access (если ты не перешёл на MS SQL). Иными словами это просто mdb файл. А значит, его можно открывать и обрабатывать "Офисными" средствами. Например, Excel. Но сначала подготовим запрос:

select Weekday(DeliveryDate, 2) as [День недели], count(*) as [Посещений]
from All__Delivery
where BookState = 'Посещение'
group by Weekday(DeliveryDate, 2)

Здесь происходит подсчёт количества посещений, приходящихся на каждый день недели. В этом нам помогает функция Weekday(), она преобразует дату в день недели. Не ищи её в справочнике SQL, это функция VB (можно посмотреть в справке к Access). По этой причине для базы на MS SQL запрос будет такой:

SET DATEFIRST 1;
select DATEPART(weekday, cast((DeliveryDate-2) as datetime)) as [День недели], count(*) as [Посещений]
from All__Delivery
where BookState = 'Посещение'
group by DATEPART(weekday, cast((DeliveryDate-2) as datetime))
order by [День недели]

Здесь всё из справочника, за исключением (DeliveryDate-2). Зачем минус два? Этот "пенёк" заслуживает отдельной статьи.

Открываем Excel. Вкладка "Данные"->"Получить внешние данные"->"Из Access".




Появится диалог похожий на открытие файла. Выбираем файл базы.




Следующий диалог выбора таблицы - просто жмём Ок.
Появится окошко "Импорт данных"



Здесь оставляем всё как есть и нажимаем "Свойства". В свойствах подключения нас интересует вкладка "Определение"



Здесь указываем "Тип команды": SQL, а в поле "Текст команды" копируем подготовленный скрипт.



Дальше всё зависит от того, работаешь ли ты с собственной копией базы (что я всячески рекомендую, кроме того офисный пакет на сервере это нонсенс) или с рабочей, параллельно с EServer. Если с копией, то ничего делать не надо. А если с рабочей, то в поле "Строка подключения" надо изменить параметры "Mode=Share Deny Write" на "Mode=Share Deny None" и "Jet OLEDB:Database Locking Mode=0" на "Jet OLEDB:Database Locking Mode=1", иначе ЗАБЛОКИРУЕШЬ РАБОТУ ОСТАЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ! Если в этот момент никто не работает с базой - тоже ничего страшного. Вообще тема режимов и блокировок для отдельной статьи. Здесь этого достаточно. Что касается MS SQL, то у него таких параметров просто нет.
Жмём Ок и получаем табличку с данными нашего запроса.



Осталось вставить диаграмму. Вкладка "Вставка"->"Диаграммы"->"Гистограмма".


Выбираем "Гистограмма с группировкой". Получаем диаграмму



В принципе всё готово. Надо только немного окультурить. Щёлкаем правой кнопкой по диаграмме, выбираем пункт меню "Выбрать данные..."



Здесь удаляем "День недели" - он уже идёт по горизонтали. Жмём Ок и выбираем "Экспресс стиль" по вкусу.



Это всё. Выглядит довольно громоздко, но на самом деле, при готовом запросе, занимает 5 минут. Можешь убедиться в этом, посмотрев небольшую видеодемонстрацию ЗДЕСЬ. Только её надо скачать, иначе при перекодировке всё теряется.
Так же можно работать и с MS SQL. Надо выбрать соответствующий источник данных. А настроить подключение не сложнее чем для EServer.
Понятно, что вид и стиль диаграммы можно выбирать и менять на свой вкус. Но это ты найдёшь в букваре по Офису, а их написано не мало. Что-то наверняка завалялось и в твоей библиотеке.
Ты спросишь, а как же Access. В нём возможностей даже больше чем в Excel. Это полноценная программируемая оболочка с графическими средствами и движком SQL.

Статистические данные можно получать с помощью "hta скрипта". Эта технология была разработана для автоматизации задач администрирования. "Hta скрипт" представляет собой HTML страницу с JavaScript. Файл имеет расширение .hta и запускается в браузере. Если табличных данных недостаточно, можно "сваять" простенькую гистограмму DIV-ами. А можно подключить какую нибудь библиотеку визуализации графиков. Получится универсальное средство, для обработки статистических данных. Я использовал эту технологию в "Скрипте проверки БД".
На этом пока всё. Пиши комментарии (регистрация не требуется) или на почту acbib3@yandex.ru

P.S.
В практике админа есть немало вещей, способных повергнуть в уныние. Но SQL в этом списке занимает особое место. Однако есть хорошая новость - если ты его осилишь, то это навсегда. Не многие технологии могут похвастаться такой фундаментальностью и долгожительством.