Mark et al, > 1) It looks like Firebird no longer returns the number of rows requested > by the client. Jaybird (wire protocol) by default requests 400 rows and > in the past Firebird always returned the requested number of rows, > unless there were no more rows (status 100). Firebird no longer seems to > honor this request and returns a lower number of rows.
At the client library level, p_sqldata_messages is not used to fetch particular M records, as M is not surfaced in our public API. Instead, fbclient tries to optimize batched fetches by asking for as much records as fits inside P (more or less hardcoded) packets. Given the message size and the protocol buffer size, it calculates M based on P and requests M rows in p_sqldata_messages. So far so good. The problem is that the aforementioned calculation almost never works properly with the asymmetric protocol. It does not consider VARCHARs that could be sent with their real (instead of declared) length. It does not consider new message formatting in the FB3 protocol (NULL bitmask is sent separately and NULL items are not sent anymore). The client simply cannot predict how long messages transmitted by the server are and how many packets they fit. So in the real world, batches were usually smaller (in terms of packets, not records) than desired. So in FB3, we've switched to server-side batch optimization. Now the server really transmits P packets (still hardcoded) at once, bit not more than M requested records. This was expected to better serve the original fbclient intentions, but obviously it breaks Jaybird and whoever else that expects exactly M records in the batch. At the moment, I can think of a simple solution: a) limit server-side batch size calculation to the FB3 protocol (and later) -- thus avoiding any compatibility issues b) within the FB3 protocol (and later), allow the client to explicitly ask for unknown (server-decided) number of rows And I need opinions on (b). I don't really want to extend the op_fetch packet with more fields. Do you think it would it be OK to reserve some special values for p_sqldata_messages to indicate this? Zero? ULONG(-1)? Any other suggestions? Besides, I'm wondering whether it would be a good idea to make P (in the case of server-side batch optimization) configurable via firebird.conf. Dmitry ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
