> > > > > > Is this during 'global destruction' (ie when a program is exiting)? > > > > Yep. So far ;-) > > I'm sure it'll only ever affect global destruction (unless > there's a bug in > your code or a very serious bug in perl's).
Could be me :). > > > > I'd like to gather some wisdom from the list here. I have a > > > situation where > > > > my dbh is being destroyed before the sth is being destroyed > and the sth > > > > doesn't have enough information anymore as the imp_dbh > > > structure is being > > > > re-used/over-written before the sth is destroyed. > > How do you know it's being re-used/over-written? > I compiled DBD::ODBC with debugging on and when I get the access violation, the debugger kicks in. I can see the imp_dbh structure that the dbd_st_destroy is getting is not right. > > > > Since the information in > > > > the imp_dbh is already being over-witten (which may be in > > > DBD::ODBC or may > > > > be from perl itself), the imp_sth has no real way of > detecting this and > > > > attempts to "clean up" where it can't. > > During global destruction "all bets are off" and you have to take > extra care. > Use the perl internals global called 'dirty' to tell if you're in > global destruction (it's a well named variable :) Look in DBI.xs to see > how I'm using it. Got it. Thanks. > > Basically if the dbh of an sth no longer looks like a dbh, then > don't use it - it's been destroyed and the database connection has > gonee. All the sth needs to worry about it tidying up as best it can. > It now seems to work, but since it always came and went, it was an issue. I've re-run the tests, but only time will tell, at this point. Thanks!!! Jeff
