Microsoft SQL Server 2005 Developer’s Guide- P28 pdf

Chapter 7: Developing with XML 249
also supported. The PORTS keyword specifies the TCP/IP port that will be used.
Supported vales are CLEAR (default 80) or SSL (default port 443). CLEAR is used
to respond to HTTP requests, while SSL requires HTTPS. Finally, the SITE keyword
specifies the name of the host SQL Server system.
The FOR SOAP clause describes the Web service. The WEBMETHOD keyword
specifies the name of the Web method that will be executed by the Web service.
The name keyword is used to link the Web method to the stored procedure on the
SQL Server system. In this example when the Web Service GetManagers method is
executed, it will in turn call the uspGetEmployeeManagers stored procedure in the
AdventureWorks database. The FORMAT key indicates the type of results that will
be returned by the Web service. Support values are ALL RESULTS and ROWSETS_
ONLY. If you want the client system to be able to consume the results of the Web
service as a dataset, then you must specify the value of ROWSETS_ONLY. While
this example uses a single Web method, you can specify multiple Web methods per
endpoint. The WSDL keyword indicates whether the endpoint supports WSDL. The
value of DEFAULT means that WSDL is supported. NONE indicated WSDL is not
supported. Alternatively, you can provide a stored procedure name to implement
a custom WSDL. The SCHEMA keyword specifies whether an inline XSD schema
will be returned for the Web method. Supported values are NOE and SCHEMA. The
DATABASE keyword specifies the name of the default database. The NAMESPACE
keyword is used to supply a namespace for the endpoint.
Once the HTTP endpoint is created, it can be accessed via a SOAP request
issued by an application. You can list the SOAP endpoints that have been created by
displaying the contents of the sys.soap_endpoints system view.
select * from sys.soap_endpoints
You can use the ALTER ENDPOINT and DROP ENDPOINT DDL statements to
manage SQL Server’s HTTP endpoints. The new HTTP endpoints are also able to
provide data stream encryption using SSL.
Using SOAP Endpoints
If the SOAP endpoint is created using the STATE value of STARTED, it can be

accessed immediately after the command completes. However, before users can
connect to the endpoint, they must be granted connect rights to that endpoint. The
basic syntax for the CONNECT ON ENDPOINT statement follows:
{ GRANT | DENY | REVOKE } CONNECT ON ENDPOINT:: <EndPointName> TO <login>
250 Microsoft SQL Server 2005 Developer’s Guide
The GRANT, DENY, and REVOKE permissions all work exactly like the
standard SQL Server object security. GRANT allows access, DENY prohibits access,
and REVOKE undoes the current permissions. The EndPointName identifies the
endpoint, and the login identifies the database login.
For instance, the following command illustrate how you might use the
GRANT CONNECT permission to enable the Sales group to connect to the
MyAdWWebService:
GRANT CONNECT ON ENDPOINT:: MyAdWWebService to HR
Querying the Web Service Using WSDL
WSDL (Web Services Description Language) is used to create XML documents that
describe a Web service. Such a document specifies the location of the service and
the operations (or methods) the service exposes. WSDL provides the information
necessary for a client to interact with a Web service. Tools such as Visual Studio
.NET and JBuilder use the WSDL to generate proxy code that client applications
can use to communicate with a Web service. If the endpoint has WSDL enabled,
that endpoint will produce WSDL when it receives a request for it. For example, the
following listing shows how to request the WSDL for our sample SOAP endpoint.
http://sql2005-2/AdwWS?wsdl
NOTE
You will need to replace the value of sql2005-2 with either the name of your server or the value
of localhost if you are running the browser on the same system as your SQL Server 2005 instance.
In this example the value of sql2005-2 is the name of the SQL Server system
where the Web service is located. The value of /AdWWS refers to the path or virtual
directory for the Web service. This corresponds to the value used in the CREATE
ENDPOINT statement’s PATH keyword. You can see an example of the WSDL

displayed in the browser in Figure 7-2.
Calling the Web Service
After the SOAP endpoint has been created and the users have been granted connect
access to the endpoint, you call the Web service from your client applications. The
following section illustrates how to build a VB.NET application that calls the Web
service. You can see the sample application in Figure 7-3.
Chapter 7: Developing with XML 251
Figure 7-2 Displaying the Web service’s WSDL
Figure 7-3 The Web service client application
252 Microsoft SQL Server 2005 Developer’s Guide
To use the sample application to call the Web service and display the result in the
grid, the user enters an employee ID number in the text box and then clicks the Call
GetManager button to execute the Web service and display the result set in the grid.
To create this project, you open Visual Studio 2005 and select a new Visual Basic
Windows Forms project. Open the designer and drag a Button control, a TextBox
control, and a DataGridView control to the design surface. After arranging the
interface elements, you need to add a reference to the Web service by selecting the
Project | Add Web Reference option, which will display a dialog like the one shown
in Figure 7-4.
In the URL prompt enter the same URL that you would use to display the Web
services WSDL. Then click Go. If Visual Studio finds the Web service, it will
be listed on the screen as you see in Figure 7-4. You can optionally rename the
reference using the Web Reference Name text box. You add the Web reference to
your project by clicking Add Reference.
After adding a reference to the Web service, you can create the code to execute
the Web service. You can see the code that calls the GetManagers Web method and
displays the results in the following listing:
Figure 7-4 Adding a Web reference
Chapter 7: Developing with XML 253
Imports.System.Data

Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
' Create a new instance of the web service
Dim MyAdWService As AdWWS.MyAdWWebService = New _
AdWWS.MyAdWWebService()
' Authenticate to use the service
MyAdWService.Credentials = _
System.Net.CredentialCache.DefaultCredentials
' The web service results converted to a DataSet
Dim ds As System.Data.DataSet = DirectCast _
_(MyAdWService.GetManagers(TextBox1.Text), DataSet)
' Display the Results
DataGridView1.DataSource = ds.Tables(0)
End Sub
To create a bit more readable code, I first renamed the Web reference from
sql2005-2 to AdWWS by right-clicking the reference in the Solution Explorer
window and then typing in the new name.
After the Web reference was renamed, the code that you see near the top of
this listing creates a new instance of the Web service, named MyAdWService.
Then the Credentials property of that object is assigned the value of System.Net.
CredentialCache.DefaultCredentials, which causes the client program to pass the user’s
Windows credentials to the Web service for authentication. Next, a DataSet named ds
is created to contain the results passed back from the Web service. The ds DataSet is
then assigned the results of the GetManagers call. The call to GetManagers passes in
the value that the user enters into a text box. After the DataSet is populated with the
results from the Web service call, it is bound to a DataGridView object and the results
are displayed to the end user.
Summary
The new XML data type adds a whole new level of relational database-XML integration
capabilities to SQL Server 2005. In this chapter you saw how to declare and use both

typed and untyped XML data values as well as how to use the FOR XML statement,
how to bulk load XML data, and how to create HTTP and SOAP endpoints for XML
Web Services.
This page intentionally left blank
255
CHAPTER
8
Developing Database
Applications with ADO
IN THIS CHAPTER
An Overview of OLE DB
OLE DB Architecture Overview
ADO (ActiveX Data Objects)
OLE DB and ADO Files
ADO Architecture
Adding the ADO Reference to Visual Basic
Using ADO Objects with Visual Basic
Advanced Database Functions Using ADO
Copyright © 2006 by The McGraw-Hill Companies. Click here for terms of use.
256 Microsoft SQL Server 2005 Developer’s Guide
I
n this chapter, you will see how to develop SQL Server database applications
using Visual Basic and ActiveX Data Objects (ADO). In the first part of this
chapter, you get a brief overview of OLE DB, with a look at the OLE DB
architecture, as well as the basic relationship of OLE DB and ADO. The second part
of this chapter illustrates the basic ADO database programming techniques used to
build SQL Server database applications.
Microsoft created OLE DB as the successor to ODBC. ODBC was primarily
designed to handle relational data, and the ODBC API is based upon SQL. While it
works well for relational database access, it was never intended to work with other,

nonrelational data sources. Like ODBC, OLE DB provides access to relational
data, but OLE DB extends the functionality provided by ODBC. OLE DB has
been designed as a standard interface for all types of data. In addition to relational
database access, OLE DB provides access to a wide variety of data sources,
including tabular data such as Excel spreadsheets, ISAM files such as dBase, e-mail,
Active Directory, and even IBM DB2 data. Using OLE DB, you can access many
different and diverse data sources using a single interface.
An Overview of OLE DB
As its name implies, OLE DB is built on an OLE foundation. Unlike ODBC, which
provides a DLL call-level interface, ADO provides a COM interface for OLE DB
that allows it to be called from other OLE-compliant applications. OLE DB has been
created with the understanding that business data is maintained in a variety of diverse
data sources. OLE DB provides a similar interface to all sorts of data. OLE DB can be
used to access any data that can be represented in a basic row and column format.
OLE DB Architecture Overview
Applications that use OLE DB are typically classified as either OLE DB providers
or OLE DB consumers. Figure 8-1 illustrates the relationship between OLE DB
providers and OLE DB consumers.
As you can see, OLE DB consumers are nothing more than applications that are
written to use the OLE DB interface. In contrast, OLE DB providers are responsible
for accessing data sources and supplying data to OLE DB consumers via the OLE DB
interface. More specifically, there are actually two types of OLE DB providers: data
providers and service providers. Data providers simply expose the data from a data
source, while service providers both transport and process data. Service providers
Chapter 8: Developing Database Applications with ADO 257
typically provide more advanced functions that extend the basic data access found
in OLE DB data providers. Microsoft Query is an example of an OLE DB service
provider, while the Microsoft OLE DB Provider for SQL Server is an example
of a data provider. As you would expect from its ODBC roots, OLE DB provides
different levels of functionality based on the capabilities of the different OLE DB

providers. While all OLE DB drivers support a common interface, each individual
driver is able to extend the basic level of OLE DB functionality. The following OLE
providers are shipped with SQL Server 2005:
᭤
Microsoft SQL Native Client OLE DB Provider
᭤
Microsoft OLE DB Provider for ODBC
᭤
Microsoft OLE DB Provider for Jet
᭤
Microsoft OLE DB Provider for DTS Packages
᭤
Microsoft OLE DB Provider for Oracle
Very similar to ODBC, each different OLE DB source uses its own OLE DB
provider. Figure 8-2 illustrates how different OLE DB providers are required to
access multiple data sources.
In this figure, you can see a high-level overview of how a Visual Basic application
might use OLE DB to access several heterogeneous data sources. With the exception
of ODBC databases, each different data source is accessed using a different OLE
DB provider. For example, SQL Server databases are accessed using SQLOLEDB,
Microsoft’s SQL Server’s OLE DB provider. Data contained in Microsoft Excel
or Exchange is accessed using their respective OLE DB providers. ODBC is an
exception to this one OLE DB provider-per-data-source rule. To provide maximum
Applications
(OLE DB Consumer)
OLE DB Interface
OLE DB Provider
Data Sources
Figure 8-1 OLE DB consumers and providers
258 Microsoft SQL Server 2005 Developer’s Guide

compatibility with existing ODBC data sources, Microsoft developed MSDASQL,
the OLE DB provider for ODBC. Unlike most OLE DB providers, which provide
direct database access, the MSDASQL OLE DB provider for ODBC accesses data
using existing ODBC drivers. The MSDASQL OLE DB provider for ODBC maps
OLE DB calls into their equivalent ODBC calls.
Each OLE DB provider delivers data access and reflects its capabilities through its
exposed COM interfaces. However, the OLE DB COM interface is a low-level interface
that requires support for pointers, data structures, and direct memory allocation. As
a result, the direct use of OLE DB providers is unsuitable for development
environments that don’t support low-level functions like pointers, such as Visual Basic,
VBA, VBScript, Java, JScript, JavaScript, and several others. This is where ADO fits in:
ADO allows OLE DB providers to be accessed by interactive and scripting languages
that need data access but don’t support low-level memory access and manipulation.
ADO (ActiveX Data Objects)
ADO is essentially an OLE DB consumer that provides application-level access to
OLE DB data sources. ADO is an OLE automation server that most OLE-compliant
development and scripting environments can access. Both OLE DB and ADO are
VB Application
ADO
OLE DB for
ODBC
(MSDASQL)
ODBC
Driver
OLE DB for
SQL Server
(SQLOLEDB)
OLE DB
Provider
OLE DB

Provider
OLE DB
Provider
Excel Exchange
Other
Data
Sources
ODBC
Data
Source
SQL
Server
Other
Figure 8-2 OLE DB overview