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 https://lists.sourceforge.net/lists/listinfo/firebird-devel
