I'm on a pretty tight deadline at the moment so my priority has been to get my app working with mysql but if I can help further (even if it is only testing) just shout.
BTW, if you are going to be looking at DBD::mysql again I hope you will consider the other bugs and fixes I've posted to dbi-users and mysql/perl lists. I can resend them if you like. In summary they were: 1. #ifdefs that should be #if in dbdimp.c 2. declaration of num_fields in the middle of a block in dbdimp.c 3. change to stop getting "FREE ERROR BIND" out on stderr when the result-set is empty (dbdimp.c) 4. change to get the error from prepare failure - simply moving a do_error up a few lines in dbdimp.c. and just in case there is any misunderstanding a) I realised 3.0002_4 was a development release but needed it for a selectrow_arrayref returning empty list issue in previous release and b) no criticism of DBD::mysql was intended - I just wanted it to work. Martin -- Martin J. Evans Easysoft Ltd, UK http://www.easysoft.com On 16-Feb-2006 Patrick Galbraith wrote: > Tim Bunce wrote: > >>[moved to dbi-dev] >> >>On Thu, Feb 16, 2006 at 11:59:31AM -0000, Martin J. Evans wrote: >> >> >>>I've finally tracked this problem down and I believe it is down to the >>>code which turns off server_side_prepare if the SQL looks like a >>>create statement. >>> >>> >> >>I'm glad you've found it. >> >> > > I second that, thank you! I want to redo the way this is done. > >> >> >>>Of course my statement looks like a create statement because: >>>o it is "select created_date_time_utc from test" >>>o the code looks for "CREATE" or "create" anywhere in the SQL >>> >>>I fixed it with the "bodge" on a "bodge" by ensuring the code looking >>>for "create" looks for "create " (but see below). However, I'd just >>>point out that it looks to me like >>> >>>o the code looking for "create" etc appears to run off the end of the >>> SQL string whilst attempting to find "create", "drop" etc >>> because it always looks up to 6 chrs past the current position and >>> the current position is eventually set to the last chr in the SQL string. >>> >>> >> >>And apart from that it should only be looking for the first word >>outside of a comment (I presume). >> >>Also I'd hope that, if it tries to do a server-side prepare and that >>fails with an error indicating that the server can't prepare that kind >>of statement, then it'll silently fallback to a client-side prepare. >> >> >> > Tim - do other drivers look at the particular error code from a failed > prepare, and if it's an error code that means 'this statement is not > supported with prep statements' you then silently toggle? > >>>o when MYSQL_VERSION >= MULTIPLE_RESULT_SET_VERSION and not doing >>> server_side_prepare the code uses my_get_fbav() then my_setup_fbav >>> and the latter appears to do a "av = newAV();" then av_store for >>> each column to extend av. I'm not an XS expert by any means but I >>> "think" this would prevent DBI's bind_columns working. >>> >>> >> >>Yes, it would (unless extra steps were taken). >> >> > > Ugh, I have been trying to figure out this issue why my_get_fbav doesn't > work properly. This is new code that Guy Harrison kindly worked on, and > I've been meaning to take time to find out what the story is to why it > has problems. > >> >> >>>I think it was the combination of the two issues above that caused >>>the issue I was seeing. >>> >>>For anyone else using DBD::mysql at the moment I'd seriously avoid >>>using an columns or tables which contain the strings >>>"create", "CREATE", "alter", "ALTER", "drop", "DROP", "show", "SHOW", >>>"call", "CALL" for now because you are likely to not get your data >>>back if you bind columns. >>> >>> >> >>Wow. That's both bad and sad. Needs fixing ASAP. >> >> > > Yes, I'll switch to doing the fix that does this more elegantly. Note - > this is a dev release (3.0002_x), so caveat emptor, though I will fix it ;) > >> >> >>>I'll happily have a go at a proper patch to fix if someone can explain what >>> >>> > >>>my_get_fbav and my_setup_fbav were written to acheive. >>> >>> > > I need to dig up what Guy said about why he wrote those, and I think > even the comments in there indicate why he did. > >> >>DBD::Sybase has support for multiple result sets. So does DBD::ODBC. >>Both still work with bind_columns - I believe (Though the DBI should >>provide a hook for drivers to call to do the kind of 're-setup' that >>multiple result sets require.) >> >>Tim. >> >> > > Tim - what do you mean about re-setup? > > Kind regards, > > Patrick
