31 Mar
2014
31 Mar
'14
11:51 a.m.
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