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
