On Fri, May 24, 2002 at 10:41:30AM +0200, Joern Reder wrote:
> "Jochen Wiedmann" wrote:
>
> > The driver does so by looking at certain Perl flags that
> > indicate whether a variable is assumed to be numeric or
> > not. In your case the arithmetic comparison is setting
> > the flags.
>
> That means, as soon as the scalar has an internal numeric representation
> (which is generated by the arithmetic comparison) you assume it's a
> numeric value. Ok, should work most of the time... ;)
>
> > If you want to ensure portability, use
> >
> > $sth->bind_param(1, $a, DBI::SQL_VARCHAR);
> > $sth->bind_param(2, $b, DBI::SQL_INTEGER);
Importing with
use strict;
use DBI qw(:sql_types);
then using
$sth->bind_param(1, $a, SQL_VARCHAR);
is recommended (using DBI::SQL_VARCHAR works but is liable to
typos not being found till runtime).
> > or
> >
> > $sth->execute("$a", int($b));
>
> I think in the case of MySQL always forcing a string context may be
> another good solution (because MySQL accepts string values for numeric
> columns), so I don't need to take care of the internal state of the
> scalar.
>
> $sth->execute("$a", "$b");
>
> This is shorter than the explicite bind_param. Ok, we have a needless
> string conversion here, but I don't think it costs more than executing
> several bind_param statements. Or do I miss something?
There are some cases where mysql does distinguish between numbers
and strings. Best to bind the right way.
Tim.