[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. > 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. > 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). > 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. > 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. 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.
