Sergei,

> SERVER_STATUS_CURSOR_EXISTS. Why is it not returned for 'reading
> metadata'? Where does the client skip it?

The server status is sent to the client twice - with the recordset
metadata and then with the resulting recordset.

You can see it in the JOIN::exec()
First we do result->send_result_set_metadata(). At this point the server_status
isn't set yet to the SERVER_STATUS_CURSOR_EXISTS. So the server status sent to the
client along with the metadata is correct.

Then we call do_select(), were we internally run the SP, which sets the
SERVER_STATUS_CURSOR_EXISTS status. So it's sent to the client with the
resulting recordset only.

Best regards.
HF


31.03.2014 7:33, Sergei Golubchik wrote:
> Hi, Alexey!
>
> On Mar 27, Alexey Botchkov wrote:
>> Hi, Sergei.
>>
>>> Why does embedded fail while a normal client-server protocol is ok with
>>> that?
>> The difference is that the client checks the server status twice during
>> execution
>> - after the metadata reading and after the actual data.
>> That SERVER_STATUS_CURSOR_EXISTS is returned on the 'reading data' stage
>> and the usual client just skips it. But for the embedded server
>> that status is same in both cases. And the 'reading metadata' part
>> crashes when it sees that server status.
>> It's in the prepare_to_fetch_result() called from mysql_stmt_execute().
> Yes, I see that prepare_to_fetch_result() checks for
> SERVER_STATUS_CURSOR_EXISTS. Why is it not returned for 'reading
> metadata'? Where does the client skip it?
>
>> I see no reason to store both statuses for the embedded server just to
>> imitate
>> the usual client's behaviour. It's better not to return the misleading
>> status in this case.
> I agree about not returning the misleading status, but I'd still like to
> understand why the regular client works.
>
> Regards,
> Sergei