returning multiple values at the same time in a function

[Andy B.]

I have some stored procedures I want to wrap into vb functions. Most of them
return 2 different kinds of data:

1. A resultset from a query. This will be used as a DataReader.
2. A status code returned from the stored procedures as output parameters
(int). I will convert these to enum values on the client.

My question is how would you return both of these from the stored procedure
wrapper function all at the same time? I would rather stay away from ByRef
values if possible since there can be lots of status codes floating around
at the exact same time and it would create lots of needless integer
variables.

 

[Fred]

in Andy B. wrote :

I have some stored procedures I want to wrap into vb functions. Most
of them return 2 different kinds of data:

1. A resultset from a query. This will be used as a DataReader.
2. A status code returned from the stored procedures as output
parameters (int). I will convert these to enum values on the client.

My question is how would you return both of these from the stored
procedure wrapper function all at the same time? I would rather stay
away from ByRef values if possible since there can be lots of status
codes floating around at the exact same time and it would create lots
of needless integer variables.

Why not return a class with a Resultset and a code as Properties ?
I don't think you need to «convert» an integer to an enum value as an
enum value can be an integer.

Public Enum SampleEnum
value1 = 5
value2 = 7
value3 = 8
End Enum

Sub Main()
Dim e As SampleEnum
e = 6
Console.WriteLine(e.ToString)
e = 7
Console.WriteLine(e.ToString)
Console.ReadLine()
End Sub

 

[Cor Ligthert[MVP]]

Hi Andy,

There is a nice article about your question on MSDn

http://support.microsoft.com/kb/308051

Cor

 

[Martin H.]

Hello Andy,

You could create a class to return data and status code, e.g.

Public Class MyReturnClass
Public ReturnValue As String
Public StatusCode As Long
End Class

Public Class TestClass
Public Function GetReturnValue() As MyReturnClass
Dim retVal As New MyReturnClass
retVal.ReturnValue="Hello World!"
retVal.StatusCode=123
Return retVal
End Function
End Class

Best regards,

Martin

 

[Cor Ligthert[MVP]]

Andy,

Maybe I have understood your question wrong, as it is about returning more
values from a function then simple create your own class and use that as the
return type.

Very ugly

\\\
Class MyReturner
public resultset as DataTable
public result as integer
End Class

Private fuction C as MyReturner
dim D as new MyReturner
MyReturner.A = ...
MyReturner.B = ....
Return D
End function
///

Cor

 

[Andy B.]

Thought about using a structure since the return values don't need the
features of a class. In the converting the status output codes to enums, I
don't want to have something like this floating around in code:

'What exactly does 100 mean?
if StoredProcedureReturnValues.NewsArticleState = 100 then
'Do whatever if enum value = 100
end if
'This would be a lot cleaner and more readable
if StoredProcedureReturnValues.NewsArticleState = NewsArticleState.Deleted
then
'Do whatever if the NewsArticle was successfully deleted.
end if

 

[Andy B.]

Why is it ugly?

Andy,

Maybe I have understood your question wrong, as it is about returning more
values from a function then simple create your own class and use that as
the return type.

Very ugly

\\\
Class MyReturner
public resultset as DataTable
public result as integer
End Class

Private fuction C as MyReturner
dim D as new MyReturner
MyReturner.A = ...
MyReturner.B = ....
Return D
End function
///

Cor

 

[Michel Posseth [MCP]]

;-)

Why is it ugly?

It isn`t really ugly but Cor probably wanted to point out that his example
is a QDE ( Quick Dirty Example ) or Pseudo code or or or ....whatever you
want to call it

The code he provided is a starter to create your wrapper cause it should be
extended depending your needs to a full functional class
for instance i would implement the values as properties , i would implement
the idisposable interface , i would create a empty and a a parameterized
constructor and .............

HTH

Michel

 

[Andy B.]

All of that just for a return values class?

;-)



It isn`t really ugly but Cor probably wanted to point out that his example
is a QDE ( Quick Dirty Example ) or Pseudo code or or or ....whatever you
want to call it

The code he provided is a starter to create your wrapper cause it should
be extended depending your needs to a full functional class
for instance i would implement the values as properties , i would
implement the idisposable interface , i would create a empty and a a
parameterized constructor and .............

HTH

Michel

 

[sloan]

You return a mini wrapper object.
But just because its mini ...doesn't mean you take short cuts with it.


Here is an example from a previous post.


public class InsertResult


private _iInsertedRowID as int32 = 0;
private _dCalculatedValue as decimal = 0;
private _returnValue as int32= 0;

''''//encapsulate the 3 variables above as properties........<< Do this and
don't use public member variables....

end class


Public Shared Function InsertProcedure(ByVal InputStuff As String) As
InsertResult

dim returnObject as InsertResult
returnObject = new InsertResult


''//Do Database Stuff


returnObject.InsertedRowID = 1 ' use your values as you have
below
returnObject.CalculatedValue= 1 ' use your values as you have below
returnObject.ReturnValue = 1 ' use your values as you have below

return returnObject


end function


At the same time.........(we had a conversation going over at
sqlserver.programming)

You need to look at the DOTNET best practices for exception handling and use
the best practices:
http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
http://msdn.microsoft.com/en-us/library/ms229014.aspx

 

[sloan]

My opinion(s) are listed after the <<


//I would implement the values as properties // <<Yes

//Implement the idisposable interface // << Optional, but depends on what
you return. If you return an IDataReader (or similar) then YES.

// i would create a empty and a a parameterized constructor // << Optional

 

[Michel Posseth [MCP]]

All of that just for a return values class?

IMHO Yes , but as stated it is just my opinion ofcourse you could also do
it the lazy way

//I would implement the values as properties // <<Yes


//Implement the idisposable interface // << Optional, but depends on what
you return. If you return an IDataReader (or similar) then YES.

I implement the idisposable interface to create inline scope ( so i use
using end using blocks ) , and if i use anny child object also implements
the idisposable
interface and yes this might also be a dataset .

// i would create a empty and a a parameterized constructor // <<

Optional

It is just to save you some typing but i always make it optional for my
users as i also expose the same parameters as property setters


HTH

Michel

 

[sloan]

//anny child object also implements
the idisposable//

Right. That's probably what I was getting at when I said "or similar", but
you stated it better.


Hopefully, he'll find a solution that works AND follows best practices!

 

[Cor Ligthert[MVP]]

Michel,

You were right what I was meaning, however in this case I feel not any
problem to use the ugly way in a program.
It adds nothing as I do it nice. This kind of classes I make not seldom in
the file at the bottom of the class that is using it.

It is something else as I use this in a library or even in a seperated file,
then I make it nice. But for this purpose not implementing Idispose as I
create not any unmanaged resource in it, however only use the reference to
that and therefore there is nothing to dispose, even a constructor for this
is an overkill becouse the only purpose of the type is to hold the
references by value to give to another member.

jmo

Cor

PS there is an quick and dirty typing error in my code it has to be
D.A = ....................
D.B = ....................

Cor

 

[Branco]

Cor Ligthert[MVP] wrote:

Very ugly

\\\
Class MyReturner
    public resultset as DataTable
    public result as integer
End Class

Private fuction C as MyReturner
    dim D as new MyReturner
    MyReturner.A = ...
    MyReturner.B = ....
    Return D
End function
///

<snip>

LOL ugly *and* meaningless, it seems: what are those methods
MyReturner.A and MyReturner.B? Wouldn't then have to be D.resultset
and D.result? =)))

Best regards,

Branco.

 

[Michel Posseth [MCP]]

Hello Cor ,

Well as i stated before i guess i am just a more strict programmer as is the
standard in this group this is probably because i once maintained libraries
that were used by a few dozen external proggers and you just don`t want them
to find anny sloppy code in your libs ;-)

About the idispose interface , first if he wants to return anny object that
exposes the idispose itself he "should" use it ( as it is a guideline ) ,
personally i made it my personal preference to implement it as it gives me a
extra scope level with Using and End Using .

Ofcourse if you know what you are doing ( and with you i am convinced of
that ) it is always possible to take a short cut for instance a parameter
class with only value types could be a candidate .

I guess the OP now understands where the ugly , dirty example stands for ,
it means he has some decissions to make but has a template on how to do it .

Regards

And good Morning to you all

Michel

 

[Cor Ligthert[MVP]]

Yes, this was an error where even the rule of parkinson was involved.

I simply wrote this sample quick and dirty in this message and started to
correct some things to make in more meainingfull where I first had nothing
in the method and then I changed the class as well

Cor

Cor Ligthert[MVP] wrote:

Very ugly

\\\
Class MyReturner
public resultset as DataTable
public result as integer
End Class

Private fuction C as MyReturner
dim D as new MyReturner
MyReturner.A = ...
MyReturner.B = ....
Return D
End function
///

<snip>

LOL ugly *and* meaningless, it seems: what are those methods
MyReturner.A and MyReturner.B? Wouldn't then have to be D.resultset
and D.result? =)))

Best regards,

Branco.