Re: Strange bind_param issue

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