On Thu, Jan 26, 2006 at 02:33:21PM -0500, Steven Lembark wrote: > > >> The only thing this doesn't pull across that I can think > >> of is the current row state of each handle > > > > You could use $sth->rows and fetch to the same row count > > (but there's no guarantee you'll be getting the same values). > > Artistic Opinion: Would reconnecting the damaged handle > and keep it usable with an appropriate error then loosing > the transaction (and letting the caller deal with it > as an exception) seem reasonable?
Yes. That would possibly suffice is all code gets its statement handles via prepare_cached(). But then if all code used prepare_cached() and connect_cached() then you wouldn't need to go down this road at all :) > > ParamValues and ParamTypes gives you a way to redo bind_param(). > > But there's no equivalent for bind_param_inout(), nor for bind_columns. > > > > Umm, bind_columns is probably do-able if the DBI gave you a way to > > access the current row array. Then you could just bind the new columns > > to the old ones. > > Any real odds? Odds? > >> Aside: How likely to change is dbh->clone as of 1.50? > >> > >> The "clone" method was added in DBI 1.33. It is very new and likely > >> to change. > > > > The more widely it's used the less likely it is to change :) > > > > The 'big issue' is how to deal with attribute values that have changed > > since the $dbh was created. > > Q: Which ones does clone use now? See the docs and then the code... Tim.
