On 20.09.2016 18:32, Martin Schreiber wrote:
> On Tuesday 20 September 2016 16:02:26 Alex Peshkoff wrote:
>> 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?
> Because in order to know that the SQL statement must be parsed. But the bigger
> problem is to know the returned data types forehand. Sure it is possible to
> obligate the users to supply that information, but most users like comfort
> and I like to support users as best as I can. ;-)
>
>> Or parameters were entered by user in a hope that
>> they will match one required by engine?
>>
> Yes. For the automatically created insert/update/delete statements for cached
> updates the parameter types are fetched from the field types of the
> resultset.
>
> [...]
>>> 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.
>>
> That is your decision of course. All I can say is that other popular DB's
> support such a mechanism since ever and I can't see what is wrong if
> IResultSet can return no row, a single row or many rows and no column, a
> single column or many columns.
> What sounds a little bit incorrect is the name openCursor() if one executes a
> non select statement. But it isn't so wrong if one thinks about a cursor as a
> row-pointer in result matrix.
> Maybe add an exec function with another name which returns an IResultSet?
Advertising
Yes, another function is also possible solution.
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
