> I suggest the following for cursor (almost same for statement):
>
> try
> {
> _cursor->close(&status);
> }
> catch (const FbException& ex)
> {
> // report error code
> _cursor->release();
> }
> _cursor = nullptr;
Thanks Alex. That nicely solved my conundrum.
--
Mgr. Jiří Činčur
On 2019-12-05 13:39, Tony Whyman wrote:
IBX's Firebird Pascal API uses the IProvider interface to get an
attachment.
It uses IAttachment to get a transaction (single database) or
IDtc/IDtcStart for a multi-database transaction.
Tony, that's absolutely OK for regular API calls. Such interfa
On 2019-12-05 12:01, Jiří Činčura wrote:
Maybe better to show some code (simplified). Expecting the free and release to
have separate responsibilities I wrote initially (the variables with underscore
are class fields). The Execute is called at some point and Free is called
either after the IEx
IBX's Firebird Pascal API uses the IProvider interface to get an attachment.
It uses IAttachment to get a transaction (single database) or
IDtc/IDtcStart for a multi-database transaction.
On 05/12/2019 10:31, Jiří Činčura wrote:
3. A transaction (ITransaction) is disposed of with a "release"
> 3. A transaction (ITransaction) is disposed of with a "release"
>
> 4. An attachment (IAttachment) is disposed of with a "detach".
Interesting. I'm getting the transaction and attachment from the
IExternalContext which si probaby slightly different. And now I'm wondering
whether I should rele
Jiři,
I've already had to go through the pain of getting the IResultSet and
IStatement interface to work when developing the Firebird Pascal API
that is distributed with IBX. The strategy that I found that works is:
1. A cursor (IResultSet) is best disposed of with "close" unless the
transac
Maybe better to show some code (simplified). Expecting the free and release to
have separate responsibilities I wrote initially (the variables with underscore
are class fields). The Execute is called at some point and Free is called
either after the IExternalFunctionImpl finished executing or in
> close/free already calls release, so no, unless you had called addRef,
> you should not call both.
>
> But I have a preference to call close/free instead release.
>
> The former will really destroy the resource (but not necessary the
> memory allocated by the object - if it has more refs) and t
