also, using bind_cols() saves a bit of time. the variables get their value assignments from the binding, so you don't need to use things like while ( my ($foo, $bar, $baz ) = $sth->fetchrow() )
UPDATE: i've double-checked some notes from a tutorial on Advanced DBI from Tim Bunce and re-consulted the Cheetah book (Programming the DBI), passing the values to $sth->execute( $foo, $bar ) on a statement prepared with placeholders explicitly calls bind_params, so there is little visible difference between explicity binding parameters ( that get into an SQL statement), but there is a visible difference for output columns ( that would use bind_col ).
bind_param IS needed to force datatype selection. and bind_param_inout is necessary for inout parameters.
using placeholders will ensure that bind_param is called anyway. one would save a check to see if the params were already bound by explicity binding them, and there may be ( this in speculation ) portability issues.
explicit binding would save on maintainability also.
and i still remember something about DB caching and DBI caching differences between explicit/implicit calls to bind_param, but i can't find the notes to back it up.
In reply to RE: RE: RE: DBI inserts and what not
by geektron
in thread DBI inserts and what not
by lindex
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |