On 15/08/2012 18:41, Tim Bunce wrote:
On Wed, Aug 15, 2012 at 06:02:35PM +0100, Charles Jardine wrote:
$obj is not a string. It is an object of a class which has a
stringify operator. "$obj" is a string, because "..." stringifies.
It is not at all clear how the DBI should take a copy of an object.
Without any method attributes in the bind_param call the driver is free
to 'do something reasonable' which typically means treat the value as a
string (or a number if it knows the field is numric).
I think this is a case of user error.
It would be reasonable for a driver to complain if passed an object that
doesn't have string/numeric overloading, but this one does.
All points taken so thanks for that but in this case although the object
does have a stringification overload as far as I can see it was not used
i.e., it was bind_param(1, $obj) not bind_param(1, "$obj") as I received
the code. If you use the latter, DBD::ODBC works but the point I'm still
uncertain about is that IF DBD::ODBC has not made a copy of the the
scalar passed to bind_param then how is it working. I will look further
but as far as I can see DBD::ODBC is simply looking at the pv on the
passed scalar and passing that pointer to SQLBindParameter and by the
time SQLExecute is called Perl may have removed the now unreferenced
scalar passed to bind_param. Having said that, I must surely be wrong on
how DBD::ODBC does this or my other example which deliberately passes a
scalar which a) is changed after the bind_param call and b) goes out of
scope before the execute call and yet inserts the value in the scalar
passed to bind_param at the time bind_param is called (that is why I
added that example).
Hopefully, this explains why this confused me a little. I did not write
the original bind_param code and need to work my way through it.
Martin
