Re: Tricks with DBI

[mpeppler]

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

[thor]

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...

[mpeppler]

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

[Anonymous Monk]

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?