Snipped this (slightly edited) from the firebird-devel list:

-------------------------------------
Samofatov, Nickolay wrote:

>
> I received 3 crash+lock up testcases which all resolve to a single issue.
> The problem is that IBO calls isc_dsql_prepare on a single statement
> handle multiple times.
>
> For Interbase 6 and FB1 this code should be causing random client-side
> or server-side crashes and/or memory corruption, but for FB 1.5 and 2.0
> this causes Access Violation in gds32.dll/fbclient.dll followed by
> lock-up if AV is handled by Delphi code.
>
> Docs don't say it is legitimate to call isc_dsql_prepare multiple times
> on a single handle. Thus we have 2 alternatives:
> 1) detect and restrict this practice throwing exception if
> isc_dsql_prepare is called on aready prepared statement. This will break
> each and every existing IBO application (but they are already randomly
> broken anyway)
> 2) do a lot of changes to make mentioned practice safe.
>
> Issue is of great imprortance because Firebird 1.5 (due to combination
> of varchar trimming and memory deallocation invalidating pointers)
> crashes much more often than Interbase 6 or FB1.

Jim Starkey answered:

>
>> Docs don't say it is legitimate to call isc_dsql_prepare multiple times
>> on a single handle. Thus we have 2 alternatives:
>> 1) detect and restrict this practice throwing exception if
>> isc_dsql_prepare is called on aready prepared statement. This will break
>> each and every existing IBO application (but they are already randomly
>> broken anyway)
>> 2) do a lot of changes to make mentioned practice safe.
>>
> Since the handle was created by allocate_statement and not prepare, it is
> legitimate to reuse the handle. The same convention is followed in JDBC
> and, if I remember correctly, ODBC.
>
> In any case, the engine may throw exceptions internally, but it returns
> errors to the user in the status vector.
>
> The only alternative is 2).

-------------------------------------

Is there anything in particular that we (as IBO developers/users) should
look out for?

--
Aage J.