On Thu, 24 Jul 2014 23:30:15 +0300, "Vlad Khorsun" <[email protected]> wrote: >> and most implementations I know with multiple result sets either require >> or allow only one result set open at a time (and if they allow multiple
>> result sets open, that is usually achieved by fully reading and >> detaching previous result sets). > > You are wrong again. I was talking about statement level, not connection or engine level. I thought that was obvious. From the perspective of a driver using the wire protocol or the client API, I have no idea how I'd open multiple result sets on a single statement handle. If this is possible, please enlighten me. > 1. Firebird supports multiply active result sets within same connection > since Interbase time > and this is one of its basic features. Note, it is implemented at the > engine level and does not > use any kind of "full fetch and close" technique. All this time we were talking about IStatement vs IResultSet, how do you (and Jim) get the idea that I was talking connection level? > 2. Statement (request) and cursor (resultset) is a different entities for > the engine and there is > no such restriction as one active cursor per statement. I.e. engine able > to produce as many > open cursors (by the same statement) as required. You could see it when > recursive procedure > is executed, for example. (I speak here about JrdStatement and jrd_req > classes, btw) I am almost always talking about DSQL or driver level. To me the internal workings how a result is produced is usually not relevant, what is relevant is how I can obtain and use a result, preferably in a way that doesn't need to much juggling and jury rigging to work with requirements of JDBC; that is also why I prefer an adherence to standards: that makes life easier (more obviousness, and less workarounds). > 3. I was a bit wrong in that that this feature is not exposed at DSQL > level, it could be used by > applications only using old BLR API (isc_start_request, isc_start_and_send) > > 4. What you speak about (as i understand) is ability to return few > resultsets (of probably > different formats) by the single execution of some statement. This feature > also exists in old > BLR API and not implemented by DSQL. An API that is - afaik - not documented. > So, currently we really have no way to call IStatement::openCursor > while previous resultset > is alive, but technically it is very possible and we should not create > artificial problems for it > even if "holy standard" have no such feature. IMHO, of course. The SQL CLI standard does have that feature: but then you have to open the second (third) etc by providing another statement handle (see NextResult). As I said above, adherence to standards make life easier, that doesn't mean that you should follow them blindly, but in this case the behaviors described in SQL CLI make sense to me (probably because the designers of JDBC also looked at SQL CLI). Mark ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
