http://www.perlmonks.org?node_id=392104


in reply to Re: Tricks with DBI
in thread Tricks with DBI

I was just curious: is this still true? Here we are four years later. Just wondering if any progress has been made on this front...

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

Replies are listed 'Best First'.
Re^3: Tricks with DBI
by mpeppler (Vicar) on Sep 20, 2004 at 06:31 UTC
    I have to admit that I haven't really tested prepare_cached with DBD::Sybase. I suspect that in certain situations this might still open multiple connections, primarily if DBD::Sybase doesn't realize that a particular query is "finished" before running another one.

    If I have the time I'll run a few tests to see what the deal is - and maybe add an override for prepare_cached in DBD::Sybase to avoid any bad surprises.

    Update: After thinking about this a little more, I want to add that with Sybase prepare_cached is really only useful for statements that include placeholders. Any other statement won't really get cached anyway, and doesn't actually get parsed/compiled/optimized until you call DBI's execute().

    Michael

      I'm using Class::DBI in conjunction with Class::DBI::Sybase. When using these modules they default to using prepare_cached for every query, and there is not an easy way to make them NOT to cache. I got it to work but by changing the Class::DBI code, which isn't good... Is there a way to force no caching, perhaps in a connection attribute?
        Not at the moment - though DBD::Sybase could be patched to alias prepare_cached() to prepare(). This would avoid the whole problem and disable prepare_cached().

        In DBD::Sybase's Sybase.pm, right after the definition of prepare() (in the DBD::Sybase::db package)

        *prepare_cached = *prepare;
        That way any call to DBD::Sybase::db::prepare_cached() will really call prepare() instead.

        Michael