On 12/09/13 14:22, Mark Rotteveel wrote:
>> Code of network operation? Something else? Upon this depends an answer.
> I think it is safe to assume that I will almost always be talking from the
> perspective of the wire protocol.
>
> Both op_create_blob and op_open_blob respond with a p_resp, which is
> defined as:
> typedef struct p_resp
> {
> OBJCT p_resp_object; // Object id
> SQUAD p_resp_blob_id; // Blob id
> CSTRING p_resp_data; // Data
> Firebird::DynamicStatusVector* p_resp_status_vector;
> } P_RESP;
>
> the p_resp_object is the handle id, while p_resp_blob_id is - in case of
> create_blob - the id of the blob (which for example can then be used in an
> insert or update statement).
Yes.
> That doesn't seem to be the case for
> open_blob.
Yes. For open_blob only p_resp_object is returned.
> Now this may seem trivial as I already have the blob id because
> I used it to open the blob, but the existing implementation in Jaybird (and
> in the .NET provider) make some assumptions with regard to the blob id in
> the response which are correct for op_create_blob(2), but seem to be wrong
> for an op_open_blob(2).
Yes. now I understand a problem. If in open_blob jaybird is trying to
use p_resp_blob_id (which is actually garbage), wrong assumption is
sooner of all too delicate word here :) This looks more like a bug.
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
