On 18.09.2016 10:24, Martin Schreiber wrote:
> Hi,
> Please bear with me if I am completely wrong, I am a simple toolmaker and no
> database specialist.
>
> MSEide+MSEgui includes a fork of the Free Pascal SQLdb framework. There users
> provide arbitrary SQL-statements and MSEgui provides the returned data in
> different forms.
> In FB 2.5 we had to prepare the statement in order to be able to setup the
> data buffers before calling execute. Preparing a statement AFAIK includes a
> server roundtrip with its latency. This is a drawback compared with other
> popular databases where no additional roundtrip is necessary.
> I hoped that that necessity does not exist anymore in the new OO-API of FB3
> but I could not find out how to work with arbitrary statements without
> prepare.
>
> In FB3 OO-API we have to know if the statement is a select statement which
> returns a cursor or another statement kind which provides no cursor.
> In the first case we call openCursor(), in the second execute().
> If the non-cursor statement returns data we have to provide a data buffer and
> an IMessageMetada interface which describes the structure of the buffer to
> execute().
> The only possibility I found to get the needed information is to call
> IAttachment.prepare() with PREPARE_PREFETCH_METADATA which AFAIK again
> includes a server roundtrip.
> In case of openCursor() the structure of the output buffer can be found by
> calling IResultSet.getMetadata().
>
> 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. 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. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
