Кеширование TSQLQuery - как отключить?

[Nick74]

Скорее всего у тебя что-то с руками не так.. У меня целая контора на ibx сидит, приложение масштаба предприятия, работает с 2мя базами на FireBird > 50гб, уже несколько лет полет нормальный, редактируют по разному и в гриде и без. Сделаю тебе тестовое приложение. Какая версия FireBird?

FB 3.0. А Лазарус у вас 32бит или 64?

[alexs]

но при возникновении ошибки от БД и повторной попытке что-то сохранить начинает ругаться на закрытый запрос и далее из ступора не выходит.

Надо с транзакциями работать правильно.
У тебя она скорее всего при ошибке комитется или ролбак - соотвенно запросы закрываются.
для этого используем обычно 2 транзакции - одна читающая, другая пишушая
1.
Тогда ошибка в пишушей и её откат не приводя к закрытию читающей
2.
Правильно настроенная читающая транзакция не потребляет ресурсов сервера.

[Nick74]

alexs
А CommitRetaining/Rollbackretaining уже не котируются?
Сейчас попробую с двумя.

Добавлено спустя 9 минут 28 секунд:
О! С двумя разными и вправду без глюков (По крайней мере IBX). Сейчас попробую UIB.
Ну точно ручки кривые )

[*Rik*]

Скорее всего у тебя что-то с руками не так.. У меня целая контора на ibx сидит, приложение масштаба предприятия, работает с 2мя базами на FireBird > 50гб, уже несколько лет полет нормальный, редактируют по разному и в гриде и без. Сделаю тебе тестовое приложение. Какая версия FireBird?

FB 3.0. А Лазарус у вас 32бит или 64?

У мня и тот и другой.
Вот пример, простой но очень полезный. В нем показано как использовать IBX c 2мя транзакциями, перехватывать сообщения об ошибках FireBird и приводить их к "человеческому" виду. Для вставки, редактирования, удаления записей используются хранимые процедуры, где проверяется правильность вводимых значений. Первичные ключи генерятся на стороне сервера в триггере и при вставке записи передаются через процедуру в IBDataSet как возвращаемое значение. В оригинальной версии IBX такого функционала нет. Т.ж. заметьте что для цифровых полей используется автоформатирование, сколько цифр после запятой указал при создании поля, столько будешь видеть на клиенте без доп. манипуляций.

Протестировано на Windows и Linux. Гарантированно будет собираться в Lazarus 1.6.4 и fpc 3.0.2 (То что разработчики Lazarus официально выложили на sourceforge). База данных (IBXTEST.FDB) создана в FireBird 3.
Проект распаковать, открыть в Lazarus, в модуле данных, в компоненте IBDatabase указать путь к базе и библиотеке FireBird, логин, пароль. Путь к библиотеке в IBDatabase нужно указывать для DesignTime (либо положите fbcliet.dll или fbclient.so где лежит сам Lazarus), когда дизайн приложения закончен, fbclient.dll или fbclient.so должен лежать рядом с исполняемым файлом вашей программы (можно в системном каталоге), а в IBDatabase путь к библиотеке стереть, при этом автоматически пропишется для Linux: fbclient.so для Windows: fbclient.dll, после этого куда бы вы не перемещали Вашу программу она будет искать библиотеку рядом с Вашим исполняемым файлом.
http://visual-t.ru/files/IBXTest.zip

[alexs]

А CommitRetaining/Rollbackretaining уже не котируются?

Команда FB это не приветствует, по крайней мере раньше было так. Там могут быть ситуации, что пойдёт гонка счётчика транзакций.
С 2мя транзакциями - оно лучше.

[pupsik]

оф.топ.
Вот странно: написал куда смотреть, дополнительно съязвив. Мне прочитали (не нужную) лекцию. А оказывается.. хм...

[Nick74]

оф.топ.
Вот странно: написал куда смотреть, дополнительно съязвив. Мне прочитали (не нужную) лекцию. А оказывается.. хм...

Я? Лекцию? Шутите? Я писал о том, чего не могу достичь и спрашивал как это можно сделать )))

Добавлено спустя 5 минут 39 секунд:
А просветите еще плиз новичка - Lazarus и Code Typhon - это все же одно и то же внутри или не очень? Компоненты от Лазаруса подойдут для КТ?

[pupsik]

или не очень?

даже о..очень не очень... А последняя дев версия - куда они прут то? Т.е., в будущем - это коммерческое приложение?

Компоненты от Лазаруса подойдут для КТ?

подойдут, или нет - это зависит того чего они будут касаться. Большей частью подойдут (как и наоборот - из тифона в лазарь). Но учтите: в тифоне много чего "затолкнули". Некоторые переплетены.

[Nick74]

http://visual-t.ru/files/IBXTest.zip

Агаааа. Вижу. Спасибо огромное! Особенно за OnAppExeption.
А можете подсказать в двух словах чем процедуры обновления/вставки/удаления удобнее триггеров?
Просто я все больше на MS SQL последние лет 12 писал, там такой жесткой необходимости все переводить на процедуры не было. Правда и триггеры там ощутимо другие...
Сходу вижу три недостатка:
1. Три лишних объекта на каждую простую таблицу, где логики может и не надо особо.
2. Переделка двух из трех процедур при малейшем изменении структуры таблицы (Новое поле добавили, скажем)
3. Невозможность точного отслеживания в процедуре что именно поменялось - разве что методом сравнения старых и новых данных. (Хм. Подумал - раньше работал на Delphi ADO, там апдейт проходил только на изменившиеся поля, не трогая неизменные, а тут если используется UpdateSQL - наверно и в триггере нифига не поймешь что меняли...) И кстати тут вообще в триггерах есть аналог майкрософтовского IF UPDATE(FLD)?

Добавлено спустя 8 минут 14 секунд:
Re: Кеширование TSQLQuery - как отключить?
О, вижу и
4. Сильный повтор логики в процедурах вставки и обновления...

[*Rik*]

http://visual-t.ru/files/IBXTest.zip

Агаааа. Вижу. Спасибо огромное! Особенно за OnAppExeption.
А можете подсказать в двух словах чем процедуры обновления/вставки/удаления удобнее триггеров?
Просто я все больше на MS SQL последние лет 12 писал, там такой жесткой необходимости все переводить на процедуры не было. Правда и триггеры там ощутимо другие...
Сходу вижу три недостатка:
1. Три лишних объекта на каждую простую таблицу, где логики может и не надо особо.
2. Переделка двух из трех процедур при малейшем изменении структуры таблицы (Новое поле добавили, скажем)
3. Невозможность точного отслеживания в процедуре что именно поменялось - разве что методом сравнения старых и новых данных. (Хм. Подумал - раньше работал на Delphi ADO, там апдейт проходил только на изменившиеся поля, не трогая неизменные, а тут если используется UpdateSQL - наверно и в триггере нифига не поймешь что меняли...) И кстати тут вообще в триггерах есть аналог майкрософтовского IF UPDATE(FLD)?

Добавлено спустя 8 минут 14 секунд:
Re: Кеширование TSQLQuery - как отключить?
О, вижу и
4. Сильный повтор логики в процедурах вставки и обновления...

Все на Ваше усмотрение, как Вам удобнее, если хотите можете вообще всю логику на клиента вынести без процедур и триггеров. Можете в триггеры все ввести, мне просто больше процедуры нравятся, поэтому я обычно их предпочитаю(даже с повтором логики, можно одну процедуру сделать на вставку и обновление) а триггеры я не долюбливаю... Иногда бывают ситуации когда нужно обновить таблицу, чтобы в ней ни чего не пересчитывалось, если есть триггеры, их нужно отключать, а процедура ни как не влияет (в этом случае если забыть выключить триггер, можно делов наворотить), но зато в триггере без лишних манипуляций доступны старые и новые значения полей OLD.FIELDNAME и NEW.FIELDNAME (Через модификатор OLD можно смотреть старые значения полей, через NEW новые, в триггере на удаление доступно только OLD, в триггерах на вставку только NEW), а в процедуре чтобы узнать какие значения полей уже имеются в записи нужно делать SELECT. Чтобы узнать в триггерах обновления что меняли, можно сравнить OLD.MYFIELD <> NEW.MYFIELD. Ещё вместо процедур можно использовать EXECUTE BLOCK, то-же самое что и процедура, только хранится на клиенте в запросах TIBDataSet (InsertSQL, ModifySQL, DeleteSQL), можете про них прочитать, может оказаться полезным. У меня на странице IBExpress описание есть как EXECUTE BLOCK в IBX использовать.
В процедурах ещё удобно данные для отчетов из разных таблиц выгребать, там данные можно крутить как угодно, в процедуре достаточно задать список выходных параметров, после этого с процедурой можно работать как с таблице (чтобы из процедуры отправить выходные данные на клиента используется команда SUSPEND для каждой строки данных). В FireBird это удобно сделано, не знаю как в MS, но в Postgres, чтобы вернуть данные в виде таблицы из функции, сперва нужно агрегатный тип объявлять, в FB удобнее..

[Nick74]

Первичные ключи генерятся на стороне сервера в триггере и при вставке записи передаются через процедуру в IBDataSet как возвращаемое значение. В оригинальной версии IBX такого функционала нет.

О, вот это интересно. А в InsertSQL, я так понимаю, можно просто указать INSERT INTO TESTTABLE (...) VALUES (...) RETURNING TESTTABLE_ID без процедуры? Очень не хватало этого.

[*Rik*]

Первичные ключи генерятся на стороне сервера в триггере и при вставке записи передаются через процедуру в IBDataSet как возвращаемое значение. В оригинальной версии IBX такого функционала нет.

О, вот это интересно. А в InsertSQL, я так понимаю, можно просто указать INSERT INTO TESTTABLE (...) VALUES (...) RETURNING TESTTABLE_ID без процедуры? Очень не хватало этого.

Да, так и есть.

После вставки и получения первичного ключа автоматически срабатывает Refresh всей записи, выполняется запрос из RefreshSQL, специально после вставки/обновления TIBDataSet.Refresh вызывать не нужно, рефрешится само, но если у TIBDataSet заполнены InsertSQL и ModifySQL то и RefreshSQL нужно заполнить.

[Nick74]

с процедурой можно работать как с таблице (чтобы из процедуры отправить выходные данные на клиента используется команда SUSPEND для каждой строки данных). В FireBird это удобно сделано, не знаю как в MS, но в Postgres, чтобы вернуть данные в виде таблицы из функции, сперва нужно агрегатный тип объявлять, в FB удобнее..

В MS SQL просто пишете в тексте процедуры любой SELECT, и он является результатом процедуры. Причем можно сделать несколько селектов, тогда процедура выдаст несколько результатов сразу, правда далеко не все умеют это обрабатывать. Пользоваться с осторожностью, скажем тот же Delphi ADO, если после SELECT в процедуре встретился THROW ERROR, его не увидит, так как для него возвращенный результат - это уже успех. В общем SELECT лучше писать в самом конце процедуры.
Процедуру можно использовать в любом месте вместо селекта, но вот использовать ее как часть другого селекта, к сожалению нельзя (Не уверен правда насчет последних версий MS SQL).
То есть написать select * from dbo.Proc или select * from (exec dbo.Proc) или exec dbo.Proc order by 1 не получится. Единственный такой разрешенный синтаксис, насколько я знаю, insert into Tbl... exec dbo.Proc
Ну и есть еще table variables, правда в MS SQL 2005 передать их как параметр в процедуру было нельзя, в последних версиях вроде уже можно.

Добавлено спустя 3 минуты 53 секунды:
Re: Кеширование TSQLQuery - как отключить?

Да, так и есть.

А можно сделать так, чтобы такой INSERT генерировался автоматически на основе указанного в поле ProviderFlags pfRefreshOnInsert? Ну и заодно вычеркнуть это поле из INSERT-списка полей )))
Вообще была бы мечта - не надо было бы НИЧЕГО делать, кроме установки ProviderFlags у одного поля...

Добавлено спустя 3 минуты 27 секунд:
Re: Кеширование TSQLQuery - как отключить?
В сочетании с новшеством FB 30 (AUTOGENERATE BY DEFAULT) - не надо было бы писать триггеры и не надо было бы редактировать сгенерированные SQL, чтобы все работало как часы ))) Блин, неужто я такой ленивый? )))

[*Rik*]

Да, так и есть.

А можно сделать так, чтобы такой INSERT генерировался автоматически на основе указанного в поле ProviderFlags pfRefreshOnInsert? Ну и заодно вычеркнуть это поле из INSERT-списка полей )))
Вообще была бы мечта - не надо было бы НИЧЕГО делать, кроме установки ProviderFlags у одного поля...
В сочетании с новшеством FB 30 (AUTOGENERATE BY DEFAULT) - не надо было бы писать триггеры и не надо было бы редактировать сгенерированные SQL, чтобы все работало как часы ))) Блин, неужто я такой ленивый? )))

В смысле чтобы запрос в InsertSQL автоматом генерился?

[Nick74]

В смысле чтобы запрос в InsertSQL автоматом генерился?

Ну да, чтобы в редакторе запросов кнопка Generate в InsertSQL сразу убирала это поле из списка Inserted полей и в конце добавляла RETURNING FLD.
Если не хочется связываться с PERSISTENT Fields - можно добавить новое свойство для датасета - а-ля AUTOGENERATEDFIELD (Ну или использовать GeneratorField->Field, не указывая имя генератора, в конце концов это оно и есть)
Кстати, если оставить InsertSQL - не будет работать вставка, или INSERT сам сформируется автоматически?

Добавлено спустя 1 минуту 45 секунд:
Re: Кеширование TSQLQuery - как отключить?
И кстати это предпочтительный вариант вместо заполнения GeneratorField->Field, GeneratorField->Generator, ведь при их заполнении происходит лишний запрос к базе, я так понимаю...

Добавлено спустя 1 минуту 20 секунд:
Re: Кеширование TSQLQuery - как отключить?
А, и из UPDATE тоже это поле убрать, зачем апдейтить автогенерируемое поле...