Firebird Embedded Temporary Table

[Strannic]

Всем доброго времени суток.
Возникла странная ситуация с Embedded.
Сама база проектировалась как серверная. В ней в качестве хранения некоторых настроечных данных использовались временные таблицы на конект. Т.е. приконектился юзер, и некоторые переменные записываются в эту временную таблицу. Сделано в частности для того, что бы не передавать постоянно некоторые параметры в хранимые процедуры, а просто сразу брать их из временной таблицы. И было это очень удобно......
Но тут решил запустить прогу под Embedded версией...
Итого.
1. Выполняется процедура, которая делает запрос к нормальным таблицам с определенными параметрами и после чего кое-что из полученных значений сохраняет во временную таблицу.
2. Данная процедура после этого комитится, дабы сохранить данные записанны во временную таблицу.
3. Делаем запрос к временной таблице - данных нет....

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

Вопрос: это баг или все таки фича?

з.ы.: версия 2.1.3, на 2.1.2 история такая же.

[hvlad]

Embedded ничем не отличается от полного сервера.
Ищите у себя или давайте воспроизводимый пример.

[Strannic]

Самый ужасный ответ (по причине того, что этого я и опасался)... Потому как я именно считал, что они не должны различаться. Однако.... Я не исключаю возможности своего "косяка", но однако как же я его в этом случае хорошо зарыл, что в случае с обычным сервером, а не с Embedded, он не проявляется воооообще ни как....
Если других мыслей нету - попробую накидать все на "чистом листе"....

[Dimitry Sibiryakov]

А у твоих временных таблиц стоит ON COMMIT PRESERVE?

[Strannic]

ну да - время жизни коннект... (ON COMMIT PRESERVE ROWS)

[hvlad]

Ну так ищи разные коннекты в (1) и (3).
Либо (1) ничего не пишет в GTT.
Либо (2) не коммитит тр-цию.

[Strannic]

конект по определению один. да и два их быть в Embedded вроде даже как не может.
время жизни конекта - это время жизни программы.
пишет или не пишет комитит или нет - сказать в Embedded версии тяжело, т.к. второго конекта к базе сделать нельзя, да и если было бы можно, то смысл? - ведь это таблица живет в рамках данного конекта.
Уверенность в том, что пишет и что конектит дает тот факт, что в обычно версии FB все работало и я даже про это забыл. А при переходе на Embedded оно всплыло... После подозрений я провел эксперемет именно с временными таблицами в версии Embedded.
Понимаю, что для чистоты надо было сделать новую базу и новый exe-шник, но пока ограничился существующим.

[hvlad]

Embedded очень даже позволяет делать сколько угодно коннектов.
Из одного процесса до FB 2.5 и из любых в FB 2.5.

Чудес не бывает, embedded - это тот же самый движок, что и полные сервер.
Так что жду воспроизводимого примера или найденной баги в приложении

[Strannic]

Да я понимаю, что фактически это одно и тоже ядро...
В частности забыл упомянуть что использую FIBPlus 6.9.6.
Однако еще раз хочу обратить внимание на то, что в обычно версии FB все работает. А в случае если бы мой процесс делал несколько конектов (что само по себе было бы странно, т.к. я лишь в одном месте делаю FIBDatabase.Open и лишь один раз), то в этом случае данные записанные при одном конекте не были бы видны в другом, т.к. все же их время жизни - конект...
Вобщем как и я говорил меня чистый пример. И вот будет огорчение, если не получу такого же эффекта, т.к. он очень устойчив в моем случае.

[hvlad]

В Fib+ есть свой монитор запросов. Надеюсь он показывает в каких тр-циях и коннектах всё происходит.

[Strannic]

Пример полностью воссоздал с чистой БД и exe. Эффект СТАБИЛЬНЫЙ! Поведение Embedded и обычного сервера различны.
Куда выслать?
Единственно - использование DevExpress и FIBPlus

[Strannic]

Итого:
вот ссылка на исходники и exe - http://promo-software.com/Bags.rar
краткое описание...
1. при коннекте к базе (через триггер на коннект) в VARIABLES (временная таблица) перекачиваются все рекорды из CONST_DB.
2. при логировке вызывается хранимка LOGIN, если пользователь найден делается новая запись в VARIABLES.

так и происходит, если это не Embedded версия.
В ней работает пункт 1. На пункте 2 запись не вставляется.

[hvlad]

Пример полностью воссоздал с чистой БД и exe. Эффект СТАБИЛЬНЫЙ! Поведение Embedded и обычного сервера различны.
Куда выслать?
Единственно - использование DevExpress и FIBPlus

DevExpress и FIBPlus у меня нет и не будет. Есть только голая D6.
Если так уж сложно сделать пример без рюшечек - давай готовый exe.
И никаких насмерть прошитых паролей и путей к БД !

[hvlad]

Вот такая процедура у тебя.

Код: Выделить всё

CREATE OR ALTER PROCEDURE LOGIN (
  LOGIN VARCHAR(32),
  PSWD  VARCHAR(33))
RETURNS (
  ID INTEGER)
AS
begin
  for
    select ID
      from USERS
     where LOGIN = :LOGIN and PSWD = :PSWD
      into :ID
  do
    suspend;

  if( ID is not null )then execute procedure VAR_SET ('ID_USERS', :ID);
end

И она не правильная.

Подсказка - приложение делает один фетч из неё.

Сам догадаешься, что не так ?

[Strannic]

1. Путей прошитых нету. Fdb в одной папке с exe должен быть.
2. Если запускал exe то видел, что там даже библиотеку сам указываешь.
3. Попробуй запустить его для начала на обычном сервере а потом с Embedded - увидишь разницу.
4. Позвольте не согласится по поводу процедуры:
а) я знаю про фетч и апдейт в одной процедуре
б) если бы это было дело в процедуре, то на обычном серваке тоже не работало бы. Однао проблема лишь при Embedded

Ок... Для корректности я пропишу FatchAll. Именно феттчол а не разнесу в по разным вызовам (!)

P.S.: кстати, попробую тоже самое провести не на временно таблице, можно будет понять в них ли дело. Ведь главное что? докапаться до истины, т.к. я прекрасно понимаю, что это один и тот же код - осталось понять почему он работает по разному....

[hvlad]

4. Позвольте не согласится по поводу процедуры:
а) я знаю про фетч и апдейт в одной процедуре
б) если бы это было дело в процедуре, то на обычном серваке тоже не работало бы. Однао проблема лишь при Embedded

Не позволю
Embedded фетчит столько раз, сколько написано в коде.
Полный сервер фетчит пачку записей, для ускорения работы в сети.
Теперь подумай - как выполнится твоя процедура, если embedded честно выполнит ровно один фетч ?

[hvlad]

Для корректности я пропишу FatchAll

Корректность нужна в процедуре.

[Strannic]

Честно говоря в такой ситуации я даже затрудняюсь ответить..............
Т.е. при этом моя логика как-то дала сбой. Все же я считал, что поведение должно быть одинаковым, но однако оно различно
Если не трудно, что бы уж совсем закрыть тему, поясни различие в этом вопросе версий Embedded и обычной.... Т.е. я так понимаю дело не во временных таблицах... Т.е. при работе с Embedded не стоит ВОВСЕ использовать select и update(insert) в одной процедуре??? А следовательно и не стоит полагаться на то, что если у вас все корректно работает на обычно версии, то оно так же ляжет на Embedded?

[hvlad]

Нужно корректно использовать SUSPEND и понимать, что он останавливает выполнение до следующего фетча.
Строго говоря, embedded работает полностью корректно, а вот сервер имеет побочный эффект из-за упреждающего фетча.
Программа неявно использует этот факт и отсюда проблемы.

В данной процедуре
а) не нужен FOR SELECT
б) SUSPEND должен быть после вызова VAR_SET
в) вообще говоря и SUSPEND не нужен, но тогда процедуру нужно вызывать по EXECUTE, а не SELECT'ом

[Strannic]

Понятно... Интересная фича...
Т.е. получается, что фактически в случае с Embedded процедура не выполняется до конца что-ли?