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?
Yes, another function is also possible solution. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel