Is it possible to unload a DBD driver from DBI?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
After I have done a DBI->connect(...), done some queries and stored
some data in some arrays, and have done a $dbh->disconnect,  can I
also "disconnect" from the installation instance of the database of
the original DBI->connect(...)?

I want to connect to a different installation that requires the same
driver, but DBI must have some installation stuff stored so that when
I set some environment variables that point to a different
installation, and do a DBI->connect(...) to a database in the
different installation I get a database doesn't exist error.

Is there a way to tell DBI to flush its current information about the
loaded driver so that a new DBI->connect(...) will force it to reload
the driver with the different installation information?



Re: Is it possible to unload a DBD driver from DBI?

droesler wrote:

Quoted text here. Click to load it

I doubt it.  You'd likely have better luck trying to convince your DBD
author to put the installation information into the connect string...

Otherwise, you may have to resort to trickery:

A) DBD::Proxy

You could set up a proxy server which basically becomes a separate process
which would use the alternate installation information.

B) use the Fork

You could fork() before using DBI, do all your work with one DBD in one
process and feed it back to the parent, and then continue with the second
installation in the parent process (the reverse is unlikely to work).  Or
you may find it better just to fork() for both installations.

Or you could do both: fork() off the proxy server, and then you can use
both, shutting down the proxy (since it's your kid) when you're done.

Both of these are FAR more work than you were obviously hoping.  But it's
still something.

Re: Is it possible to unload a DBD driver from DBI?

On Jan 12, 3:06=A0pm, Darin McBride
Quoted text here. Click to load it

Thanks Darin,

That is FAR more work than I was hoping :-)  I ended up writing the
data out to a file and in another script read the data in and
processed it as needed in another installation.


Site Timeline