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


in reply to Tricks with DBI

Great article - however: And, for the same reasons, you should use prepare_cached instead of prepare.

Don't use prepare_cached() with DBD::Sybase - this would open multiple connections to your server (one for each cached statement handle). If you have a need to have a few requests that you are going to call a *lot* you may want to create stored procedures for them instead.

Michael

Replies are listed 'Best First'.
Re^2: Tricks with DBI
by thor (Priest) on Sep 19, 2004 at 04:02 UTC
    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

[reply]
      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

[reply]
        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]

In Section Tutorials