On 20.09.2016 12:25, Martin Schreiber wrote:
> On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote:
>>> A convenient solution of the dilemma would be if openCursor() would work
>>> with any SQL statement.
>>> It seems that a part of that solution already works, calling openCursor()
>>> with "
>>> insert into TABLE1 (STR1) values ('aabbccdd') returning PK
>>> "
>>> and getting result metadata by calling getMetadata() on the returned
>>> IResultSet actually returns a valid buffer description. What apparently
>>> not works yet is calling fetchNext(), it throws a
>>> "
>>> Cursor is not open
>>> "
>>> error.
>> I suppose it's possible to have pseudo-cursor in mentioned case, but
>> telling true at the first look the fact that openCursor() does not fail
>> for such statement looks like a bug. And your solution is anyway
>> incomplete - if SQL has input parameters you anyway need prepare to
>> execute it.
> No, input parameters are supplied by the user by "TParams" class where the
> types are known. MSEgui uses an IMessageMetadata descendant in order to
> supply the input data, please see attachment.

If it knows parameters... why does this particular framework does not 
know statement type? Or parameters were entered by user in a hope that 
they will match one required by engine?

>> On the other hand in FB4 we are going to add interface making it
>> possible to execute really any SQL statement without explicit prepare
>> before it (as a side effect of batch API). Therefore I suggest not to
>> use hack-like tricks but wait for next version. I'm sure that fb4
>> release cycle will be _much_ shorter compared with fb3.
> Hmm, please no offence meant, but FB has the reputation to be "not usable over
> the Internet". We know why. ;-)
> I think if an exec-like API function works for any statement-kind it is no
> hack but orthogonal design.

Martin, suppose I was not precise enough. API able to execute any 
statement kind without prior prepare is certainly useful. I just wanted 
to say that modifying behaviour of openCursor() and letting IResultSet 
fetch from non-cursor object is hardly correct solution. Moreover 
internally firebird engine has not problems doing it - the only issue is 
how better access it from outer world. And in FB4 we have plans to add 
such API.

Firebird-Devel mailing list, web interface at 

Reply via email to