Всем здравствуйте. Ткните носом если этот вопрос уже обсуждался.

Картина следующая - имеется Firebird 2.5 в архитектуре CS и приложение из пары окон ввода данных. Все пишущие транзации короткие - стартуют вручную и завершаются жестким коммитом. Читающая транзация стартует в состоянии pre-commited. И вроде бы все хорошо, но в MON$STATEMENTS регулярно остаются записи я так понимаю подготовленных запросов вот такого вида:


В приложении эта инструкция выполняется компонентой IBSQL. Если после ExecSQL выполнить Unprepare, то запись в MON$STATEMENTS не остается. Непонятно почему сохраняются только некоторые из таких инструкций - все они одинкаово формируются, все параметризированны, все выполняются по одной схеме - старт транзации - выполнение инструкции - коммит. Получается что для некоторых курсор освебождается автоматически, а для некоторых только после уничтожения коннекта?

Но почему тогда я вижу только некоторые? Явного освобождения не делаю нигде

Dimitry SibiryakovЗначит, твоя программа работает совсем не так как ты о ней думаешь.

Спасибо ....
У меня-то формы уничтожаются по закрытию, а раз так - то вызывается деструктор TIBSQL, а раз вызывается - значит выполняется Unprepared в InternalFreeHandle. Вот и все объяснение.

Я тут подумала немножко и у меня назрело еще вопросов.

Если выполнять запрос в isql то после коммита подготовленные запросы исчезают. Хотя соединение остается активным. То же касается выполнения запросов в IBExpert. При коммите из клиентского приложения подготовленный запрос сохраняется либо до уничтожения компонента, связаного с ним, либо до разрыва соединения.

Я так понимаю что освобождение происходит при вызове isc_dsql_free_statement. По крайней мере судя по наблюдению в SQL мониторе. В трекере FB есть ссылка где разработчики говорят о том что в версии 2.5 добавлена специальная константа DSQL_unprepare, которая позволяет не только уничтожить сам дескриптор стэйтмента, но и сделать SQL инструкцию unprepared. Поковырявшись в исходниках IBX TIBSQL.pas (у меня версия 16.16 Delphi XE2) я не обнаружила нигде передачи этого параметра в вызов isc_dsql_free_statement. Только DSQL_close или DSQL_drop, причем передача DSQL_drop выполняется только в деструкторе и соответственно если явно не вызывать метод Unprepare - то это и даст наблюдаемую мной картину.

Так что я подозреваю что при работе isql и IBExpert вызывают isc_dsql_free_statement(DSQL_close|DSQL_unprepare) или isc_dsql_free_statement(DSQL_drop|DSQL_unprepare) что позволяет сразу освободить подготовленные запросы, в то время как IBX выполняет isc_dsql_free_statement(DSQL_close) и isc_dsql_free_statement(DSQL_drop).

Хотелось бы понять в правильную сторону ли я думаю?

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

Гаджимурадов Рустам, вопрос в том почему при выполнении запросов через IBExpert и isql подготовленные запросы освобождаются, а при работе через IBX - без явного Unprepare - нет? Собственно и все получается

hvlad, не сложно конечно. Весь мучающий меня вопрос в 17942742

tanyxahvlad, не сложно конечно. Весь мучающий меня вопрос в 17942742
Футы.. на ночь глядя уже не то пишу. Вопрос в 17942752

Вот оно что. Спасибо большое за ответ. Я и не знала что isc_dsql_execute может так использоваться. В моем представлении сначала должен быть isc_dsql_execute ..... и потом в конце isc_commit_transaction

А еще совсем глупый вопрос - очень ли плохо если этих запросов много кэшируется? Например для одного коннекта их может быть 80-90 шт. А соединений таких около полусотни. Влияет ли это как-то на работу базы?

Гаджимурадов Рустамtanyxa> Я и не знала что isc_dsql_execute может так использоваться

Это тараканы isql. IBE (кроме скриптера) так не работает.

Но ведет себя похоже ))) Наверное использует DSQL_drop, судя по тому что каждый раз при выполнении запроса заново делает prepare

Гаджимурадов Рустамtanyxa> для одного коннекта их может быть 80-90 шт.
tanyxa> А соединений таких около полусотни.
tanyxa> Влияет ли это как-то на работу базы?

Господи, девушка, не смешите людей.

Я постараюсь :)

hvladtanyxaочень ли плохо если этих запросов много кэшируется?Они жрут память.
Я думала что если сам запрос уже выполнен, значит клиент уже получил запрошенные данные и это не более чем сохраненный текст в метаданных

hvladtanyxaНаверное использует DSQL_drop, судя по тому что каждый раз при выполнении запроса заново делает prepareДля того, чтобы сделать prepare, не нужно делать DSQL_drop.
Извините, может косноязычно выражаюсь - я говорю о том что при выполнении запроса и последующего коммита - подготовленый запрос освобождается.