Bug in Firebird Embedded 2.1 ?

[Cherevatenko Vsevolod-2]

Добрый день !

Столкнулся с таким фокусом:

В Firebird Embedded 2.1 (2.1.3.18185) и в Firebird 2.1 SuperServer
(2.1.2.18118), на классике не проверял, нижеприведенный код возвращает
разные результаты. Firebird Embedded во внутреннем селекте не находит
записей, которые там на самом деле есть.

For Select Doc_PKey, Doc_Day, Number, Amount, Account_A, Account_B,
MFO_A, MFO_B,
                OKPO_A, OKPO_B, Details
     From KRB_From_Bank
     Where Doc_Day = :Doc_Day And
               Pay_Type = 2 And
               Account_A = :Account
     Into :PKey, :Doc_Day, :Number, :Debet, :Account_A, :Account_B,
           :MFO_A, :MFO_B, :OKPO_A, :OKPO_B, :Details
     Do
     Begin

         if ( Not Exists
                ( Select Doc_PKey, Number, Amount, B, Details
                  From Krb_Out
                  Where Account_A = :Account_A And
                            Account_B = :Account_B And
                            MFO_A = :MFO_A And
                            MFO_B = :MFO_B And
                            OKPO_A = :OKPO_A And
                            OKPO_B = :OKPO_B And
                            Number = :Number And
                            Amount = :Debet And
                            Doc_Day = :Doc_Day And
                            Doc_Status in ( '5', '6', '7', 'A' )
                          ) ) Then
                Begin
                    Pay_Type = 2 ;
                    Credit = NULL ;
                    Suspend ;
                End

     End


Переписал этот кусок процедуры на следующее и все стало Ок :

     For Select k.Doc_PKey, k.Doc_Day, k.Number, k.Amount, k.Details
           From KRB_From_Bank k
           left join Krb_Out o on
                k.Account_a = o.Account_a
                and k.Account_b = o.Account_b
                and k.Mfo_a = o.Mfo_a
                and k.Mfo_b = o.Mfo_b
                and k.okpo_a = o.okpo_a
                and k.okpo_b = o.okpo_b
                and k.Number = o.Number
                and k.amount = o.Amount
                and k.Doc_day = o.Doc_day
                And o.Doc_Status in ( '5', '6', '7', 'A' )
           Where
                k.Doc_Day = :Doc_Day
                And k.Pay_Type = 2
                And k.Account_A = :Account
                And o.Doc_pkey is Null
           Into :PKey, :Doc_Day, :Number, :Debet, :Details
           Do
           Begin

             Pay_Type = 2 ;
             Credit = NULL ;
             Suspend ;

           End
     End

[Dmitry Yemanov-2]

Cherevatenko Vsevolod wrote:
>
> Столкнулся с таким фокусом:

Базу выслать можешь?


--
Дмитрий Еманов

[Cherevatenko Vsevolod-2]

On Nov 10, 8:09 pm, Dmitry Yemanov <dim...@...> wrote:
> Базу выслать можешь?

Тут есть небольшая проблема. Это таблицы базы Клиент-Банк с финансовой
информацией клиента (входящие и исходящие платежи). Попытался сделать
воспроизводимый пример на тестовой базе, но сходу не вышло :( Попробую
еще раз, может заскремблирую критичные поля, воспроизведу ошибку и
тогда пришлю.

С уважением,
Всеволод.

[Cherevatenko Vsevolod-2]

Добрый день !

> Базу выслать можешь?

Вести с полей. Определил, что все дело в поле Amount (Decimal(15,2))

На Firebird Embedded вот этот запрос не находит запись :

Select *
From Krb_Out
Where
Amount = 1659516.96

а вот такой - находит :

Select *
From Krb_Out
Where
CAST(Amount as varchar(15)) = '1659516.96'

Что интересно, добавлял поле такого же типа, заполнял его значениями
из "проблемного" поля - ошибка исчезала.

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

На Firebird Super - все Ок. На классике, подозреваю, что тоже все
нормально.


Сделал воспроизводимый пример. Убил геть все, оставил одну таблицу с
несколькими полями и несколько сотнями записей. Размер бекапа
получился ~ 13K. Куда слать ?

С уважением,
Всеволод.

[Sergey Mereutsa-2]

Превед!

> Вести с полей. Определил, что все дело в поле Amount (Decimal(15,2))

> На Firebird Embedded вот этот запрос не находит запись :

Ой, кажись, кого-то щаз будут бить... или пошлют читать маны...


--
Best regards,
 Sergey                            mailto:gebelezis@...

[Cherevatenko Vsevolod-2]

> Превед!
>
> Ой, кажись, кого-то щаз будут бить... или пошлют читать маны...
>
 И тебе "превед", добрый человек :)

Sorry: NUMERIC(15,2)

Или все равно пошлют ? :)

С уважением,
Всеволод.

[Dmitry Yemanov-2]

Cherevatenko Vsevolod wrote:
>
> Определил, что все дело в поле Amount (Decimal(15,2))

Диалект не первый часом?

> Сделал воспроизводимый пример. Убил геть все, оставил одну таблицу с
> несколькими полями и несколько сотнями записей. Размер бекапа

А после рестора оно что, тоже воспроизводится? Если нет, то нафига мне
бекап?

> Куда слать ?

firebird2 at yandex dot ru


--
Дмитрий Еманов

[Cherevatenko Vsevolod-2]

>
> Диалект не первый часом?
>
  Диалект 3.
>
> А после рестора оно что, тоже воспроизводится? Если нет, то нафига мне
> бекап?
>

  Конечно воспроизводится. Я бы не отвлекал и не поднимал этот вопрос.

> firebird2 at yandex dot ru

  Отправил.

[Dmitry Yemanov-2]

Cherevatenko Vsevolod wrote:
>
> Отправил.

Спасибо. Любопытный случай.

Несмотря на 3-й диалект базы поле DECIMAL(15, 2) оказалось физически
создан как DOUBLE вместо BIGINT. Возможно, этот столбец добавлялся в
*коннекте* с 1-м диалектом.

Бага связана с режимом оптимизации компилятора и вылазит где-то между
преобразованием numeric-константы к double и сравнением двух double
между собой на равенство. При компиляции любого из задействованных
модулей в режиме "strict" вместо "precise" проблема уходит.

Причем тут именно embedded - пока неясно. Вроде бы режимы FPU,
задаваемые хост-программой, на это никак не должны влиять.


--
Дмитрий Еманов

[Cherevatenko Vsevolod-2]

> Несмотря на 3-й диалект базы поле DECIMAL(15, 2) оказалось физически
> создан как DOUBLE вместо BIGINT. Возможно, этот столбец добавлялся в
> *коннекте* с 1-м диалектом.

 Спасибо за разъяснения. Теперь понятно почему при добавлении нового
поля такого же типа и переноса данных в это поле, проблема исчезала.
Непонятно, а как это поле, вернее его значение, переживает
backup&restore ? И еще один вопрос, как найти поля с такими фокусами в
БД.

Вообще-то структура БД тянется еще с времен IB, но переход на 3
диалект был произведен еще лет 8 назад. Странно, что вылезло только
сейчас при таком количестве инсталяций системы ( ~ 15 тыс.). Можно
предположить, конечно, что редко используется именно Embedded версия
птицы.

С уважением,
Всеволод.

[Dmitry Yemanov-2]

Cherevatenko Vsevolod wrote:

> Непонятно, а как это поле, вернее его значение, переживает
> backup&restore ?

Бекап просто копирует данные из системных таблиц. А там все нормально -
поле double и значение в нем тоже double.

> И еще один вопрос, как найти поля с такими фокусами в БД.

Ищи записи в RDB$FIELDS с RDB$FIELD_TYPE = 27 и ненулевым
RDB$FIELD_SUB_TYPE.


--
Дмитрий Еманов

[Cherevatenko Vsevolod-2]

>
> Бекап просто копирует данные из системных таблиц. А там все нормально -
> поле double и значение в нем тоже double.
>

 Ясно.

> Ищи записи в RDB$FIELDS с RDB$FIELD_TYPE = 27 и ненулевым
> RDB$FIELD_SUB_TYPE.
>

 Нашел еще пару таких полей. Проапдейтил эти поля

update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'RDB$1126'
where (RDB$FIELD_NAME = 'COMMISSION') and
(RDB$RELATION_NAME = 'KRB_FROM_BANK')

сделал backup&restore и мои волосы стали шелковистыми :)

Спасибо.

Правда остался еще один вопрос, если вынести за скобки все эти
манипуляции и объяснения почему для этой таблицы по этому полю селект
при использовании Embedded возвращал пустое множество, это таки бага
или нет ?

С уважением,
Всеволод.

[Dmitry Yemanov-2]

Cherevatenko Vsevolod wrote:
>
> Правда остался еще один вопрос, если вынести за скобки все эти
> манипуляции и объяснения почему для этой таблицы по этому полю селект
> при использовании Embedded возвращал пустое множество, это таки бага
> или нет ?

Конечно. Только пока не ясно, чья именно :-)


--
Дмитрий Еманов