RE: RE: DBI inserts and what not

I've never understood the point to 'bind_param()', unless you really need to tell the driver what datatype the binding needs to be. I've always passed the parameters in during execute(), and haven't had any trouble (yet).

I usually DO use bind_columns() for the select statements, although this particular question was about an insert statement.

Update: Regarding geektron's comment below, my only point was about using bind_param() explicitly as opposed to binding the parameters at execute time. I believe it does the same thing (please correct me if I'm wrong), and the only reason to use bind_param explicitly is to change the default bind_type.

(7 years later)Update: Well, I've finally gotten around to needing bind_param...now that I'm using DBI with Sybase (it just doesn't seem to like the default bindings sometimes).

Comment on RE: RE: DBI inserts and what not

Replies are listed 'Best First'.
RE: RE: RE: DBI inserts and what not by geektron (Curate) on Sep 29, 2000 at 06:44 UTC
why would one use bind_param() and bind_cols()? speed. it might take a bit more programmer time, but it removes database transaction time - which is usually the bottleneck in scripts. 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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

RE: RE: RE: DBI inserts and what not
by geektron (Curate) on Sep 29, 2000 at 06:44 UTC

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.

[reply]
[d/l]
[select]