On Thu, Feb 16, 2006 at 11:27:21AM -0500, Patrick Galbraith wrote: > Tim Bunce wrote: > > >I'm glad you've found it. > > I second that, thank you! I want to redo the way this is done.
Great. > >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? I'm not aware of any other drivers that need to. (Personally I think the mysql server should have 'emulated' prepared statements itself for those that it should genuinely prepare.) But does it matter what other drivers do? > >>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 ;) > >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 - what do you mean about re-setup? Different result sets may have different numbers of columns, column names, column types etc. Some $sth attributes like NAME, TYPE etc may have been cached by the DBI and need clearing out. Similarly get_fbav needs to be nudged into returning refs to correctly sized arrays. It would be best if the DBI provided a hook to look after that, but I'd need input from driver authors about what they actually need. (I've not looked closely as the DBD::ODBC or DBD::Sybase code that handles it.) Tim.
