By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,389 Members | 2,070 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,389 IT Pros & Developers. It's quick & easy.

SQL Server stored prcedures with output parameters

P: n/a
Has anyone, with any driver whatsoever, managed to retrieve output
parameters from a SQL Server stored procedure? I've just been rather
embarrassed to find out it's not as easy as it might seem, and people
are saying bad things about Python as a result :-(

mx.ODBC, which I regard as a highly-capable module, does not support the
callproc() API, and suggests use of the ODBC call format. It has caveats
in (some of) the documentation implying that output parameters cannot be
handled due to their indeterminate memory requirements, however.

The adodbapi module does have a stored procedure call in its unit tests,
and manages to pass that test, but when I call my own stored procedure
(which retrieves columns into the output parameters rather than using
SET to establish their values) I get back whatever value I supplied as
the output parameter rather than what the stored procedure is returning.

So, can anyone help me to fulfill what must be a very common database
requirement?

regards
Steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119
Jul 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Steve Holden wrote:
Has anyone, with any driver whatsoever, managed to retrieve output
parameters from a SQL Server stored procedure? I've just been rather
embarrassed to find out it's not as easy as it might seem, and people
are saying bad things about Python as a result :-(

mx.ODBC, which I regard as a highly-capable module, does not support the
callproc() API, and suggests use of the ODBC call format. It has caveats
in (some of) the documentation implying that output parameters cannot be
handled due to their indeterminate memory requirements, however.

The adodbapi module does have a stored procedure call in its unit tests,
and manages to pass that test, but when I call my own stored procedure
(which retrieves columns into the output parameters rather than using
SET to establish their values) I get back whatever value I supplied as
the output parameter rather than what the stored procedure is returning.

So, can anyone help me to fulfill what must be a very common database
requirement?

regards
Steve


Hmmm, following up, added another test to adodbapi to retrieve a value
from a table into an output parameter it works, so this puts the
suspicion on to the stored procedure. Since this was written by the
client I'll take a look at it later (when I'm back in the office) and
see what the problem might be.

happily-talking-away-to-myself-ly y'rs - steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119
Jul 18 '05 #2

P: n/a
Steve Holden wrote:

Hmmm, following up, added another test to adodbapi to retrieve a value
from a table into an output parameter it works, so this puts the
suspicion on to the stored procedure. Since this was written by the
client I'll take a look at it later (when I'm back in the office) and
see what the problem might be.

happily-talking-away-to-myself-ly y'rs - steve


However, the stored procedure below appears to consistently return zero
for the link_id when called with:

columnist_id, url, title, description, link_id = \
curs.callproc("sp_InsertArticle",
(columnist_id, url, title, description, 0))

so maybe there really *is* something wrong. Or, hopefully, I'm just
making a simple mistake in the calls? Whatever value is used as the
fifth (output) parameter seems to get returned, despite the apparent
change in the stored procedure.

Create PROCEDURE dbo.sp_InsertArticle
(
@columnist_id int,
@url varchar(255),
@title varchar(99),
@description text,
@link_id int OUTPUT
)
AS
BEGIN
INSERT INTO link (columnist_id,url,title,description)
VALUES (@columnist_id,@url,@title,@description)

SELECT @link_id = @@IDENTITY
END

GO

not-quite-so-happi-ly y'rs - steve
--
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119
Jul 18 '05 #3

P: n/a
In article <HHWmd.10924$nj.1324@lakeread01>,
Steve Holden <st***@holdenweb.com> wrote:

Has anyone, with any driver whatsoever, managed to retrieve output
parameters from a SQL Server stored procedure? I've just been rather
embarrassed to find out it's not as easy as it might seem, and people
are saying bad things about Python as a result :-(

mx.ODBC, which I regard as a highly-capable module, does not support
the callproc() API, and suggests use of the ODBC call format. It has
caveats in (some of) the documentation implying that output parameters
cannot be handled due to their indeterminate memory requirements,
however.


Keep in mind that it's been several years since I used Python with SQL
Server and about all I remember is that we used stored procedures
heavily with no problems. I have no clue whether we tried using stored
procedures with output parameters, but I wonder why you can't just use a
SELECT to call the stored procedure and return the values. Or at least
right another stored proc that does something roughly similar.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

WiFi is the SCSI of the 21st Century -- there are fundamental technical
reasons for sacrificing a goat. (with no apologies to John Woods)
Jul 18 '05 #4

P: n/a
In article <cn**********@panix1.panix.com>, Aahz <aa**@pythoncraft.com> wrote:

Keep in mind that it's been several years since I used Python with SQL
Server and about all I remember is that we used stored procedures
heavily with no problems. I have no clue whether we tried using stored
procedures with output parameters, but I wonder why you can't just use a
SELECT to call the stored procedure and return the values. Or at least
right another stored proc that does something roughly similar.


s/right/write/, but you knew that.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

WiFi is the SCSI of the 21st Century -- there are fundamental technical
reasons for sacrificing a goat. (with no apologies to John Woods)
Jul 18 '05 #5

P: n/a
Steve Holden <st***@holdenweb.com> wrote in message news:<oSYmd.10931$nj.6308@lakeread01>...
Steve Holden wrote:

Hmmm, following up, added another test to adodbapi to retrieve a value
from a table into an output parameter it works, so this puts the
suspicion on to the stored procedure. Since this was written by the
client I'll take a look at it later (when I'm back in the office) and
see what the problem might be.

happily-talking-away-to-myself-ly y'rs - steve


However, the stored procedure below appears to consistently return zero
for the link_id when called with:

columnist_id, url, title, description, link_id = \
curs.callproc("sp_InsertArticle",
(columnist_id, url, title, description, 0))

so maybe there really *is* something wrong. Or, hopefully, I'm just
making a simple mistake in the calls? Whatever value is used as the
fifth (output) parameter seems to get returned, despite the apparent
change in the stored procedure.

Create PROCEDURE dbo.sp_InsertArticle
(
@columnist_id int,
@url varchar(255),
@title varchar(99),
@description text,
@link_id int OUTPUT
)
AS
BEGIN
INSERT INTO link (columnist_id,url,title,description)
VALUES (@columnist_id,@url,@title,@description)

SELECT @link_id = @@IDENTITY
END

GO


I had a similar problem doing this once before that I think was
related to the connection string. Changing to use the SQLOLEDB
provider solved it. I've just tested the below script here and got
the expected results:

Stored procedure:

CREATE PROCEDURE TestSP
@param INTEGER OUTPUT
AS
BEGIN
select @param = 10
END

Python test:

import adodbapi

server='localhost'
dbname='brian'
user='sa'
password=''

db=adodbapi.connect('Provider=SQLOLEDB.1;Data Source=%s;Initial
Catalog=%s;User ID=%s;Password=%s;'%(server, dbname,user,password))
cur = db.cursor()
print cur.callproc('TestSP',(999,))
[10]

--
Brian
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.