суббота, 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