Greg Stark writes:
> Michael Peppler <[EMAIL PROTECTED]> writes:
>
> > Greg Stark wrote:
> >
> > Actually not - Sybase creates a temporary stored proc for each prepared
> > statement, so it's equivalent to using stored procedures.
>
> Heh neat, is that DBD::Sybase or the server that's doing that?
> And does it only work for a single statement handle or does it keep
> that procedure around in case i prepare the same statement again?
The prepared statement uses a stored proc built on the fly *if* your
SQL statement has ?-style placeholders. With Sybase you can't have
multiple statements that are active simultaneously over the same
connection, so preparing a second statement will result in DBD::Sybase
opening a new connection (as a side note you *can't* use this feature
when AutoCommit is OFF because it would require DBD::Sybase to do
two-phase commits, which I'm not prepared to code at this point...)
The stored procs remain around for as long as the $sth is
defined/valid.
Another good point is that Sybase *knows* what types the various
parameter to a prepared statement are, so you don't need to tell it
that something is a VARCHAR or whatever (and I actually ignore those
type params to execute() and bind_param())
That being said Sybase is pretty fast at parsing/compiling SQL, so
using ?-style placeholders is really only usefull if you're going to
call a particular statement more than a couple of times.
And in general, with Sybase I always advocate using stored procs for
all access as this allows the DBA to fine tune the queries without
having to go into the perl code itself (and ensures that you don't get
someone issuing a very sub-optimal query that brings a system to its
knees!)
Michael
--
Michael Peppler -||- Data Migrations Inc.
[EMAIL PROTECTED] -||- http://www.mbay.net/~mpeppler
Int. Sybase User Group -||- http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]
