http://qs321.pair.com?node_id=392298


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

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

Replies are listed 'Best First'.
Re^4: Tricks with DBI
by Anonymous Monk on Dec 24, 2005 at 16:46 UTC
    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?
[reply]
      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;

      [download]
      That way any call to DBD::Sybase::db::prepare_cached() will really call prepare() instead.

      Michael

[reply]
[d/l]
        Thanks for the suggestion Michael. I'll stick with modifying Class::DBI since that seems less of a sin than modifying DBD::Sybase. In addition, we have many more dependencies on DBD::Sybase then on Class::DBI, which we're just introducing... Thanks again!
[reply]

In Section Tutorials