[DB-SIG] stored procedures

[Mike Skowronski]

thanks for the info.  I tried the fetchXXX() stuff and it didn't work --
odbc returned `invalid cursor state' error.  I'd like to have output
values available in db-api; it's easy enough to implement in the database 
api's that i'm familiar with, though i'm not sure how making it a 
requirment, if stored procs are supported, may affect the support of other
databases.

Mike

On Wed, 3 Feb 1999, M.-A. Lemburg wrote:

> Mike Skowronski wrote:
> > 
> > Hi,
> > 
> > I'm using the odbc module w/ python 1.5.1 to call stored procedures and
> > they work fine except when the procedure (or the return value on
> > a function) has an output value.  For example if I have something like:
> > 
> >         ret = 0
> >         params = [ret, 1, 2]
> >         aCursor.execute('{? = call addthem(?,?)}', params)
> > 
> > the value of ret would always be 0 even though if i call the same function
> > from C or pl/sql it behaves correctly -- i.e. adding the 2 input
> > parameters for above e.g.  any suggestions?
> 
> The current DB-API does not handle output parameters for
> cursor.execute().
> You could try to produce a result set though and use that for
> output data via the .fetchXXX() methods.
> 
> I suggested an improvement on this for the next version of the DB-API 
> Spec. a couple of weeks ago, but have gotten next to no response so far. 
> Maybe this message could revive the discussion...
> 
> """
> 2. Stored procedures
> 
> Basically I want to revisit the discussion. The 1.1 proposal
> defines this interface:
> 
> callproc(procname,list_of_parameters) 
>               This method is optional since not all databases
>               provide stored procedures. 
> 
>               Call a stored database procedure with the given
>               name. The list of parameters must contain one
>               entry for each argument that the procedure
>               expects. The result of the call is returned by
>               modifying the list contents in place. Input
>               parameters are left untouched, output and
>               input/output parameters replaced with the new
>               values. 
> 
>               The procedure may also provide a result set as
>               output. This must then be made available through
>               the standard fetch-methods.
> 
> Is this general enough to fit everybody's needs ? I know that
> Jim Fulton would rather like an interface which returns a callable
> type... but it seems overkill to ask module writers to implement
> this just to be DB API conform.
> """
> 
> [The message I quoted this from has the subject line 
>  "[DB-SIG] API Enhancements"]
> 
> -- 
> Marc-Andre Lemburg                               Y2000: 331 days left
> ---------------------------------------------------------------------
>           : Python Pages >>> http://starship.skyport.net/~lemburg/  :
>            ---------------------------------------------------------
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 
>