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?
Advertising
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?
Thanks, Martin
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
