On Fri, Sep 30, 2016 at 12:40:02AM +0100, Russell Howe via dbi-users wrote: > On Thu, Sep 29, 2016 at 11:30:08PM -0000, Greg Sabino Mullane wrote: > > > > > Should a call to prepare() return an Active statement? (i.e. > > > $sth->{Active} == 1) > > > > > > This appears to be the behaviour of DBD::Sybase, but not DBD::Pg > > > > I don't think there is a canonical answer to that, but I can say that > > DBD::Pg in most cases will not even talk to the server until the first > > execute() after the prepare(), so it not being Active seems a sane > > interpretation.
> > The docs for DBD::Pg: > > > > Indicates if a handle is active or not. For database handles, this > > indicates if the database has been disconnected or not. For statement > > handles, it indicates if all the data has been fetched yet or not. > > Use of this attribute is not encouraged. > > > > As far as I can tell, DBD::Sybase makes not effort to do anything special > > regarding that attribute. > > DBD::Sybase has this > > /* Re-enable the active flag here (in 1.05_03) to fix bug with > finish not getting called correctly */ > DBIc_ACTIVE_on(imp_sth); > > at the end of syb_st_prepare() in dbdimp.c > > So, it explictly sets Active to deal with some issue that I haven't > fully delved into. > > > In short, I would not rely upon it, especially across DBDs. > > That's unfortunate, because Class::DBI does. > > $ grep -r Active . > ./lib/Class/DBI.pm: $sth->execute(@$args) unless $sth->{Active}; > > (from sth_to_objects) > > As far as I can see, this is to work out whether the sth that's been > passed in has already had execute called on it (e.g. part of a multiple > result loop). Removing the $sth->{Active} check (and ensuring Ima::DBI > always calls prepare and not prepare_cached (I haven't figured out what's > going on there yet) gets Class::DBI working with DBD::Sybase. > > Our current code overrides db_Main which seems like an unnecessary hack > to me, and confuses Class::DBI somewhat, triggering warnings. > > I'm halfway down this rabbit hole and not really sure which turning to > take now! I'd take the view that $sth->{Active} shouldn't be true until after a successful execute(). I'd happily take a doc patch that tightens up the docs in that direction. Tim.