The above function returns a DataSet object. After the initial set of variables are declared, the With statement-block is executed and certain attributes within the sqlCmd SqlCommand object are set accordingly. It’s probably important to note the if-else block within the With block. If the passed parameter determines the stored procedure’s name that is specified in the SqlCommand object’s CommandText.
After the With block has been finished, SqlDataAdapter is instantiated and its instance’s SelectCommand is set and an instance of DataSet is created. The SqlDataAdapter object’s Fill method is invoked. This version of Fill is originates from the SqlDataAdapter and was not inherited from the DataAdapter class (or, interface I think).
What’s really strange is that the function is able to return something and still close the SqlConnection instance, or be able to do anything else for that matter, afterwards. This is kind of “cool” but also kind of annoying because I don’t see why they would do this. I’m not sure in what situations would having something like this be useful in a programming language.
The original author gives an example of some Visual Basic code that allows the client-side application to recreate the returned DataSet.
Typed DataSets
A “typed” DataSet is any subclass that is derived from the DataSet object. If you created your own typed DataSet, then an XML Schema must be defined in an XSD file.
The following XML code creates a new DataSet subtype called “candyTypeDataset”:
The above example has an XML element named “element”, whose name attribute is set to equal “candyTypeDataset”, defines a Visual Basic class with the name candyTypeDataset. Before the first element tag is closed, another element tag is defined. With this inner element’s name attribute set to “candyType”, the candyType property is created inside of the candyTypeDataset class.
The following Visual Basic code is an example of a Web Service method that sends the newly created candyTypeDataset data type to be returned to the client-side application:
To have the return type recognized by the client-side application, the Web Service on the server-side has to have been created and a “reference” to it on the client-side must be set. After this is done, the client-side application can interact instances of the typed DataSet like any other object that was defined on the client’s side.
The following code is an example of access to the candyTypeDataSet object from the client-side:
1: Dim ws As New localhost.SweetsService
2: Dim ds As localhost.candyTypeDataset
3:
4:
5: ds = ws.GetCandyTypes
Now, rather than trying to navigate the various methods and data structures that are used to navigate the relationships between the different members of the DataSet, the candyType field is accessed directly through the candyType attribute of the candyTypeDataset object.
I’m assuming that the candyType attribute is determined by whatever’s returned from the “sp_GetCandyType” stored procedure. But. what’s perplexing to me is how does .Net know that? I didn’t see this defined in either the XSD or the Visual Basic script examples above.
After the With block has been finished, SqlDataAdapter is instantiated and its instance’s SelectCommand is set and an instance of DataSet is created. The SqlDataAdapter object’s Fill method is invoked. This version of Fill is originates from the SqlDataAdapter and was not inherited from the DataAdapter class (or, interface I think).
What’s really strange is that the function is able to return something and still close the SqlConnection instance, or be able to do anything else for that matter, afterwards. This is kind of “cool” but also kind of annoying because I don’t see why they would do this. I’m not sure in what situations would having something like this be useful in a programming language.
The original author gives an example of some Visual Basic code that allows the client-side application to recreate the returned DataSet.
[FONT='Courier New', courier, monospace]
[FONT='Courier New', courier, monospace] 1: Dim ws As New localhost.wsSubmit
2: Dim xmlStatus As DataSet
3: xmlStatus = ws.GetRequests(RequestedStatus:=False) [/font]
[/font]2: Dim xmlStatus As DataSet
3: xmlStatus = ws.GetRequests(RequestedStatus:=False) [/font]
Note: I don’t know what “localhost” is here.
Somehow, an instance of a WebService is instantiated by using the wsSubmit attributed of the localhost variable. The passed parameter given to the GetRequests function is set to false, so the stored procedure is “spGetClosedRequests”.
Typed DataSets
A “typed” DataSet is any subclass that is derived from the DataSet object. If you created your own typed DataSet, then an XML Schema must be defined in an XSD file.
The following XML code creates a new DataSet subtype called “candyTypeDataset”:
Code:
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema id="candyTypeDataset" targetNamespace="http://tempuri.org/CandyType.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/CandyType.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="candyTypeDataset">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="candyType" minOccurs="0" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>The above example has an XML element named “element”, whose name attribute is set to equal “candyTypeDataset”, defines a Visual Basic class with the name candyTypeDataset. Before the first element tag is closed, another element tag is defined. With this inner element’s name attribute set to “candyType”, the candyType property is created inside of the candyTypeDataset class.
The following Visual Basic code is an example of a Web Service method that sends the newly created candyTypeDataset data type to be returned to the client-side application:
PHP:
<WebMethod()>
Public Function GetCandyTypes() As candyTypeDataset 'db connection Dim sqlConn As SqlConnection
Dim sqlCmd As SqlCommand
Dim strConstring As String
Dim intUserID As Integer strConstring = ConfigurationSettings.AppSettings("constring")
sqlConn = New SqlConnection(strConstring)
sqlConn.Open()
sqlCmd = New SqlCommand
With sqlCmd
.Connection = sqlConn
.CommandTimeout = 30
.CommandType = CommandType.StoredProcedure
.CommandText = "sp_GetCandyType"
End With
Dim CandyDA As SqlDataAdapter = New SqlDataAdapter
CandyDA.SelectCommand = sqlCmd
Dim CandyDS As New candyTypeDataset
CandyDA.Fill(CandyDS, CandyDS.Tables(0).TableName)
Return CandyDS
sqlConn.Close()
End FunctionThe following code is an example of access to the candyTypeDataSet object from the client-side:
1: Dim ws As New localhost.SweetsService
2: Dim ds As localhost.candyTypeDataset
3:
4:
5: ds = ws.GetCandyTypes
Now, rather than trying to navigate the various methods and data structures that are used to navigate the relationships between the different members of the DataSet, the candyType field is accessed directly through the candyType attribute of the candyTypeDataset object.
I’m assuming that the candyType attribute is determined by whatever’s returned from the “sp_GetCandyType” stored procedure. But. what’s perplexing to me is how does .Net know that? I didn’t see this defined in either the XSD or the Visual Basic script examples above.
