Outputting Data From Stored Procedure

[Jarrod Morrison]

Hi All

Im generally a vb programmer and am used to referencing multiple records
returned from a query performed on an sql database and im trying to move
some functions of my software into sql stored procedures. So far ive been
able to move the functions relatively easily but im unsure about how to
output multiple values from an sql stored procedure. By this i mean for
example one of the stored procedures may take your username and return the
contents of a single field in a record of one of the tables, but i would
like to be able to return for arguement sake the contents of a single field
from two records if possible. Under VB im used to referencing the recordset
with a (1) after it to reference the corresponding record from the query. I
was wondering if there is a way to do something similar to this with stored
procedures if possible ?

Thanks for any help

[Erland Sommarskog]

Jarrod Morrison (ja*****@ihug.c om.au) writes:

Thanks for the post, thats exactly what i wanted. But i have one further
question about the second part of the post, when i execute the select
statement inside the stored procedure it is actually part of a loop and
thus each select statement is being treated seperately by VB, so if i
use query analyzer i see for example 3 seperate returns which is ok
because it is what is meant to be returned, however vb is only reading
the first one of these returns and then closing the recordset. Im sure
there is an easy way around this but im unsure of what to do. Any help
is greatly appreciated

As Ellen K said, you can use .NextRecordset to access the remaining
recordsets.

However, you should probably redesign your stored procedure. First of
all, maybe you don't need that loop. There are situations when you
need to run loops in T-SQL, but programmers who are used to VB, C and
the like but are not well versed in SQL, tend to use loops far more
often than they need. There can be a huge performance gain in replacing
a loop with set-based processing.

But even if you cannot replace the loop, you should probably not return
data for each turn in the loop. Not only does it make you VB processing
more complicated, but it is also ineffecient in regards to network
resources. Rather than returning data to the client, you can insert
the data into a table variable or a temp table, and then have a SELECT
at the end of the loop that returns data from the temp table.
--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Samuel Hon]

Erland Sommarskog <so****@algonet .se> wrote in message news:<Xn******* *************** @127.0.0.1>...

Jarrod Morrison (ja*****@ihug.c om.au) writes:

Thanks for the post, thats exactly what i wanted. But i have one further
question about the second part of the post, when i execute the select
statement inside the stored procedure it is actually part of a loop and
thus each select statement is being treated seperately by VB, so if i
use query analyzer i see for example 3 seperate returns which is ok
because it is what is meant to be returned, however vb is only reading
the first one of these returns and then closing the recordset. Im sure
there is an easy way around this but im unsure of what to do. Any help
is greatly appreciated

As Ellen K said, you can use .NextRecordset to access the remaining
recordsets.

However, you should probably redesign your stored procedure. First of
all, maybe you don't need that loop. There are situations when you
need to run loops in T-SQL, but programmers who are used to VB, C and
the like but are not well versed in SQL, tend to use loops far more
often than they need. There can be a huge performance gain in replacing
a loop with set-based processing.

But even if you cannot replace the loop, you should probably not return
data for each turn in the loop. Not only does it make you VB processing
more complicated, but it is also ineffecient in regards to network
resources. Rather than returning data to the client, you can insert
the data into a table variable or a temp table, and then have a SELECT
at the end of the loop that returns data from the temp table.

I've never found a need to use .NextRecordset yet. As Erland says,
better stored procs are the way forward. Have you got a sample loop
that you can post?

[Erland Sommarskog]

Samuel Hon (no*****@samuel hon.co.uk) writes:

I've never found a need to use .NextRecordset yet. As Erland says,
better stored procs are the way forward. Have you got a sample loop
that you can post?

You haven't? For me whose favourite client library i DB-Library, it
seems obvious that you should use .NextRecordset. There may not be
any more recordsets to pick up, if there is and you don't get them,
you can run into surprises. (With DB-Lib and ODBC you will get an error
on next access. ADO will open a new connection, but that may still lead
to unexpected behaviour.)

A presumption for ditching .NextRecordset completely is that you use
SET NOCOUNT ON consistently.
--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Ellen K.]

I've actually never used it either... but I know it exists. :)

On 15 Dec 2003 01:53:29 -0800, no*****@samuelh on.co.uk (Samuel Hon)
wrote:

I've never found a need to use .NextRecordset yet.

[Jarrod Morrison]

Hi Erland

Well i did at first attempt to insert all the data into a temporary table in
sql, and at the end say select * from #tablename, but when i try to access
the data from the vb program i recieve the error

Runtime error 3265

Item cannot be found in the collection corresponding to the requested name
or ordinal

I am using the example that samuel posted previously as the basis for my
coding and it returns data correctly if i do select statements on non
temporary sql tables fine but when it is on a temporary table i recieve the
above error. Below is the stored procedure i am working on

CREATE PROCEDURE [dbo].[TestProcedure01]

@EntityLocation ID VarChar(300)

AS

DECLARE @SrchCount VarChar(3) /* Search Loop Count */
DECLARE @SrchInt VarChar (3) /* Current Search Position */

SET @SrchInt = 1
SET @SrchCount = (LEN(@EntityLoc ationID) - 1) / 3

CREATE TABLE #AvailPrint (Path VarChar(60), Name VarChar(30), Priority
Char(1), LocationID VarChar(300))

WHILE @SrchInt <= @SrchCount

BEGIN
INSERT INTO #AvailPrint(Pat h,Name,Priority ,LocationID) SELECT *
FROM Printers WHERE LocationID LIKE RIGHT(LEFT(@Ent ityLocationID,
@SrchInt * 3 + 1),3)
/*SELECT * FROM Printers WHERE LocationID LIKE
RIGHT(LEFT(@Ent ityLocationID, @SrchInt * 3 + 1),3)*/
SET @SrchInt = @SrchInt + 1
END

SELECT * FROM #AvailPrint
GO

What this procedure does at the moment is to pull out 3 records from a table
and place them into the temporary table (The number of records is not fixed
and is dependant on the input variable @EntityLocation ID), nd it outputs a
table in query analyzer fine. If i change the procedure so that the INSERT
INTO line is remarked out (Put a /* */ around it) and remove the remarks on
the line below the query analyzer returns the 3 records but they are
seperated, so when i use the vb program i am only able to access the first
record of data. Im not sure how to structure the procedure without the loop
as im used to using vb loops so any help with this is greatly appreciated

Thanks

[Erland Sommarskog]

Jarrod Morrison (ja*****@ihug.c om.au) writes:

Well i did at first attempt to insert all the data into a temporary
table in sql, and at the end say select * from #tablename, but when i
try to access the data from the vb program i recieve the error

Runtime error 3265

Item cannot be found in the collection corresponding to the requested name
or ordinal

I am using the example that samuel posted previously as the basis for my
coding and it returns data correctly if i do select statements on non
temporary sql tables fine but when it is on a temporary table i recieve
the above error. Below is the stored procedure i am working on

The error message is from Visual Basic, and means that the index you
are using to address a collection is not valid.

I would guess tha the reason is that one or more of the columns in
the temp table, does have the same name as the colunms in the
Printers table, but you have failed to amend the VB code for this.

Permit me to note, that I would not have to resort to guessing, if
you also had included the VB code you are using, and you had replace
SELECT * FROM Printers with the actual columns. In my opinion,
"SELECT *" from permanent tables should not be used in stored
procedures, because the procedure could break if someone adds a new
column to the table. (From this follows that SELECT * from the temp
table is OK.)

--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp