Коллеги, нужна помощь.

Попал в руки старый чужой проект, который надо было немного доработать. До этого никогда с FireBird дел не имел (я ораклист со стажем). При добавлении нового интерфейса в проект столкнулся с необъяснимой ошибкой. Выражается она в том, что в интерфейсе проекта в гриде одно (и только одно!) поле показывается с ошибочным значением.

Теперь подробно. В FB есть вьюха со следующим кусочком кода:




Смысл этого поля - показать, сколько дней прошло с момента оформления последнего объекта типа ORDER.

Содержимое этой вьюхи я показываю в гриде, реализованном на компоненте TDBGridEh из библиотеки EhLib версии 4. Для доступа к данным используется библиотека FIBplus версии 7.6, компонент FIBDataSet.
В компоненте созданы статические поля (Fields), т.к. есть потребность в полях тип Lookup. Теперь собственно проблема: при открытии этой View из средства SQL-разработки (IBExpert) я вижу корректное значение этого поля (неоднократно проверял вручную по исходным таблицам). Но вот при запуске моего проекта в соответствующей колонке видны значения на 2 или 3 единицы МЕНЬШЕ !!!!! Ну т.е. через IBExpert вижу, например, значение поля "3", а в интерфейсе своего проекта - "1". Подобное уменьшение значения происходит по всей колонке (т.е. по всем строкам датасета).

Столкнувшись с проблемой впервые, подумал, что причина кроется в статически созданных полях (я тогда активно менял наполнение той самой вьюхи, и подумал, что идет неправильный мапинг полей на буфер строки данных ), и заново пересоздал все Fields объекта FIBDataSet. Ошибка ушла, значения стали показываться корректные. НО! Через несколько дней, НА ТОМ ЖЕ exe-ФАЙЛЕ ошибка вернулась. Я опять запускаю Delphi, удаляю все Fields и пересоздаю их заново - проблема уходит. Опять не трогаю проект, опять проходит 2-3 дня - и опять ошибка в визуализации!!!! И опять пересоздание Fields решает проблему.

Коллеги, какие есть идеи о причинах подобной мистики?

Проверял. Неподтвержденных транзакций нет. Вообще никаких параллельных транзакций нет.

Не отстают, время верное.

Какая разница? Я говорю что неподтвержденных транзакций нет, и это точно.

А вот это мне в голову не пришло, ступил. Спасибо.

Вообще, наблюдение за ситуацией наводит на идиотскую мыль о том, что фраза


будучи вставленной во VIEW, превращается сервером в константу в момент компиляции VIEW.
Я несколько дней подряд наблюдал за поведением приложения, при том, что не прикасался к exe-файлу вообще, и даже специально запускал его не из среды разработки. Так вот, на протяжении последних 3 дней, ошибка в данных увеличивалась на минус единицу в каждый следующий день (!). Честно говоря в шоке от такого. Сейчас наплодил тестовых VIEW, проверю их после выходных (чтобы дата компиляции отличалась от текущей даты). Но если гипотеза подтвердится..... Просто нет слов.

Вот за что я люблю русскоязычные форумы, так это за неистребимое желание научить тебя жизни.

Да, я не буду тратить немеряно времени на то, чтобы описывать методику проверки на наличие транзакций. Просто потому, что время будет потрачено неэффективно: у меня нет необходимости кому-то что-то доказывать, а надо найти ошибку в системе. Мне дали дельный совет про транзакции (спасибо!) - я проверил и убедился, что дело не в этом. Поэтому ищу дальше.



Какие все блин умные.... Читаем:

https://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-functions-contextvars.html#fblangref25-contextvars-today

'TODAY' is not a variable but a string literal. It is, however, special in the sense that when you CAST() it to a date/time type, you will get the current date.
...
'TODAY' always returns the actual date, even in PSQL modules, where CURRENT_DATE, CURRENT_TIME and CURRENT_TIMESTAMP return the same value throughout the duration of the outermost routine.




Я начал вспоминать, как именно проверял выдачу этой VIEW, когда получал якобы правильные данные в IBExpert. Так вот, у меня был открыт SQL-редактор с текстом VIEW, я комментировал в нем строчку "alter view ... as" и запускал на выполнение получившийся голый SELECT. Так казалось удобнее, чем писать в отдельном окне select * from view . Так что проверка была, в общем-то, невалидной - но мне и в голову не могло прийти, что один и тот же запрос может отработать по-разному, будучи запущен отдельно или внутри view. За 20 лет работы с Ораклом ничего подобного не встречал, поэтому кейс подсознательно не рассматривал.

Сегодня сделал именно select * from view - и получил в выдаче ту же ошибку в данных, что наблюдаю в приложении. Это собственно и подтолкнуло к гипотезе о некорректной отработке литерала 'TODAY' внутри view.

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


Неее, брат. В коде написано :


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

Трындец.
Кстати, вот еще подтверждение нашел: 10304342 и 5468611
И ни в одной документации этого нет. Зашибись.

Что ж, проблема решена, всем спасибо.

PS Ну его нафиг этот Firebird с такими приколами, в какой-то момент решил что реально крыша едет. Пойду обратно в Оракл, там как-то поспокойнее.

Откуда эта цитата? Я привык ориентироваться на англоязычную оригинальную (официальную) документацию, ссылку привел выше, и там ничего подобного нет.

Понятно. В данном случае имеем, что вычисление константы происходит в момент открытия хэндла.

Но у меня ситуация несколько иная. Фиксация значения происходила в момент компиляции VIEW (и я это уже проверил экспериментально). Не очень понимаю, при чем тут хэндл.