Comparing SQL Server 2005 and IBM DB2 v8.2 as a Database Platform for

Visual Studio and .NET Developers

Revision 1.0

October, 2004

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Active Directory, Microsoft, Visual Basic, Visual C++, Visual C%, Visual Studio, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks

of their respective owners.

Contents Contents 2 Abstract 5 Summary of Study Results 5 Introduction 6 Comparison of Core Technologies 6

Data Providers ...............................................................................................7 .NET Framework Integration.............................................................................8 Implications of the Hosting Model......................................................................9 Differences Between .NET 2.0 and .NET 1.1........................................................9 Deploying .NET Logic to SQL Server ................................................................10 Securing Assemblies in SQL Server .................................................................10 Deploying .NET Logic to DB2 ..........................................................................11 Visual Studio and SQL Server 2005 Integration .................................................11 Visual Studio and DB2 UDB 8.2 Integration ......................................................13 Manageability and Performance ......................................................................15

Technical Walkthrough 17 Description of SQL Server 2005 CLR Stored Procedure 17 Building a Stored Procedure with SQL Server and Visual Studio 2005 19

Summary of Steps in Development Process ......................................................19 Tools Integration ..........................................................................................19

Description of a DB2 CLR Stored Procedure 30 Building a Stored Procedure with DB2 and Visual Studio 32

Summary of Steps in Development Process ......................................................32 Tools Integration ..........................................................................................32

Summary Comparison of the Developer Experience 41 Beyond the Relational Database 42

HTTP Endpoints ............................................................................................42 Service Broker .............................................................................................42 Notification Services......................................................................................42 Reporting Services........................................................................................43 Integration Services......................................................................................43 Analysis Services ..........................................................................................44 Mobile Edition ..............................................................................................44

Conclusion 45 About the Authors.........................................................................................46

Abstract This study compares and contrasts SQL Server 2005 with DB2 UDB v8.2, from the perspective of a Visual Studio 2005 developer. The study compares the core technologies used by both SQL Server 2005 and DB2 UDB 8.2, such as .NET Framework integration, support for language and other enhancements, and performance and manageability. The study then follows the steps necessary to build, debug, and deploy a stored procedure using SQL Server 2005. These steps are then compared to the steps required to build, debug, and deploy the same stored procedure using DB2. The intended audience for this article includes architects, developers, and technology decision-makers.

Summary of Study Results The study shows that the combination of SQL Server 2005 (code named “Yukon”) and Visual Studio offers significant advantages over DB2 UDB 8.2 (code named “Stinger”) and Visual Studio for building database applications. These advantages will save organizations both time and money as they develop, debug, and deploy database solutions within their organizations. Specifically, this study demonstrates that SQL Server 2005 supports a significantly wider range of .NET database objects than DB2 UDB 8.2. Additionally, the SQL Server 2005 and Visual Studio combination provides a much deeper level of integration than the combination of DB2 UDB 8.2 and Visual Studio for building and managing database objects. The study also demonstrates that beyond the relational database development capabilities, SQL Server 2005 offers an application development platform that extends beyond the capabilities offered by DB2 UDB 8.2.

Introduction In the past, the IT development world consisted of isolated lands of proprietary knowledge of application development languages, production environments, and data manipulation routines. Building bridges between these islands of technology often required specialized skills and was labor intensive. Today, with SQL Server 2005 and Visual Studio 2005, we see a unified development environment that includes programming models that span a broad range of software solutions from client-based database applications and server management utilities to the creation of server-side database objects. Developers and customers alike receive the benefits of enhanced tools and framework functionality, which translates to a global increase in application usability, performance, security, and scalability.

The integration of the Visual Studio environment and the database data providers that are found in SQL Server 2005 and DB2 8.2 simplify and improve the application development process. They offer enhanced productivity tools for building and deploying application programs resulting in better performance, both in development time and application manageability. Both SQL Server 2005’s and DB2 UDB 8.2’s integration with the .NET Framework produce a more productive and flexible database application development environment that results in better performing, more robust database solutions that possess better manageability and scalability than any of the previous versions. By taking advantage of .NET integration, database developers are able to perform tasks that were impossible to achieve using just procedural SQL code. Using the .NET Framework, developers can write code that has more complex logic, is better suited to computation problem solving, and can access external system and network resources. The .NET languages like Visual Basic, C# and C++ are all fully object-oriented languages with capabilities such as encapsulation, inheritance, and polymorphism. They also provide full support for a number of features that aren’t present in SQL like support for arrays, structured exception handling, and collections.

Microsoft .NET delivers the most advanced and productive environment for building and integrating database applications today. In this study, we will compare the different levels of .NET integration provided by SQL Server 2005 and DB2 UDB 8.2. To illustrate the exact nature of each of the different product’s integration capabilities, we provide a detailed technical walkthrough showing the exact steps required to build a sample .NET stored procedure using both SQL Server 2005 and DB2 UDB 8.2 with Visual Studio.

Comparison of Core Technologies While both SQL Server 2005 and DB2 UDB 8.2 are integrated with the .NET Framework and Visual Studio, there are some significant differences in the respective level of integration provided by these products. The following table presents the major comparison points for the two database platforms with regard to the level of their .NET integration.

.NET Capabilities SQL Server 2005 DB2 UDB 8.2

Native .NET Data Provider Yes (SQL Server .NET Yes (DB2 .NET Data

Data Provider) Provider)

.NET Stored Procedures Yes Yes

.NET User Defined Functions Yes Yes (requires manual creation)

.NET Triggers Yes No

.NET User Defined Types Yes No

.NET User Defined Aggregates

Yes No

Visual Studio tooling Yes Yes

Data Providers Both SQL Server 2005 and DB2 UDB 8.2 provide native .NET Data Providers that enable .NET client applications to access the database platform. These “native” providers offer higher performance and better scalability for server applications, as compared to providers based on OLE DB. These two providers offer very similar capabilities. Both providers implement the basic ADO.NET Connection, Command, DataReader, DataSet and DataAdapter objects. One key difference: the SQL Server .NET Data Provider is made available in two modes, one for client applications and one for server applications. This is particularly important for server side development because the SQL Server server-side .NET Data Provider is an in-memory provider that doesn’t have the networking overhead that’s associated with client-side data access providers. Being an in-memory provider provides higher performance for .NET database objects. In addition, the separate server side provider exposes a set of capabilities such as server-side cursors that are only appropriate for server-based code. The provider for client applications is exposed via the System.Data.SqlCient namespace while the .NET Data Provider for server side database objects is found in the System.Data.Sqlserver namespace. For DB2 UDB 8.2 there is the single IBM.Data.DB2 namespace. The DB2 .NET Data Provider uses the DB2Context object to create an in-memory connection to the database.

On the server side, again there are similarities. Both DB2 and SQL Server support the creation and subsequent server-side deployment of application logic in .NET languages. Beyond this basic concept, the level of .NET integration with the two database platforms is quite different. DB2 UDB 8.2 supports the creation of .NET stored procedures and user defined functions. However, only the creation of DB2 UDB 8.2 .NET Stored Procedures is supported in the Visual Studio IDE. DB2 UDB .2 .NET Functions must be created manually. In contrast, SQL Server 2005 provides much broader support for .NET. Like DB2, SQL Server supports the creation of .NET stored procedures and user defined functions. However, SQL Server also supports .NET for use within triggers, user defined types (UDT’s), and user defined aggregates. The creation of all of these objects is fully integrated within the Visual Studio 2005 IDE. The ability to build stored procedure and functions using the .NET languages enables the database developer to implement business logic and perform complex functions that are beyond the capabilities of standard SQL. This is certainly a key point for .NET interaction with the database, but the ability to use the .NET languages to create triggers, user defined types, and

aggregates are just as important. Using.NET for triggers enables the trigger code to more fully encapsulate business logic and perform additional actions such as accessing external resources for logging operations. The ability to create user defined types enables the database developer to extend the native data types that are supplied with the system. UDT’s defined with .NET can have their own properties and operators enabling the developer to seamlessly extend the native data types that are supported by the server. These UDTS can function exactly like native data types having their own customer operators and aggregates. Similarly, the ability to support user defined aggregates enables the developer to create custom aggregation operators that can be used with either native or user defined data types.

Beyond the basic set of .NET features provided, there are important differences in the way that the .NET Framework is integrated with the respective database servers. The next section will discuss the .NET integration details in more depth.

.NET Framework Integration Microsoft® .NET is a set of Microsoft software technologies for connecting information, people, systems, and devices. The .NET Framework is an integral Windows component for building and running the next generation of software applications and Web services. The .NET Framework:

• Supports over 20 different programming languages.

• Manages much of the plumbing involved in developing software, enabling developers to focus on the core business logic code.

• Makes it easier than ever before to build, deploy, and administer secure, robust, and high-performing applications.

The .NET Framework consists of the common language runtime (CLR), and a unified, factored, hierarchical set of class libraries. The .NET CLR’s responsibilities include run-time services for language integration, security enforcement, and management of memory, processing, and threading. In the area of language integration, the CLR defines the common type system (CTS), which describes the basic data types common across all .NET languages, and the operations that pertain to those data types. The .NET Framework provides an extensive set of classes that developers can incorporate into their applications, covering areas such as I/O, networking, text processing, data access, encryption, XML processing, Web services, and more. This allows developers to focus on building business logic rather than plumbing code. The integration of the .NET CLR with both SQL Server 2005 and DB2 UDB 8.2 enables the development of database objects using any of the .NET languages including C#, Visual Basic, C++, and J#.

The manner in which the two different platforms are integrated with the .NET Framework is quite different. The SQL Server 2005 database engine hosts the CLR “in-process”. This means that there is only a single operating system process that runs both the database engine and the .NET runtime. In contrast, DB2 UDB 8.2 uses an “out-of-process” model for .NET integration. You can see a visual depiction of the different database CLR implementations in Figure 1.

Figure 1 - Database CLR Integration

Implications of the Hosting Model An in-process model to host the .NET runtime offers SQL Server 2005 several distinct advantages over an out-of-process model. First, hosting the CLR in-process enables SQL Server to control the execution of the CLR in various important ways. The vital functions of memory management, garbage collection, and thread support are under the control of the SQL Server host, rather than using .NET’s default settings and behavior. This is important because the SQL Server database engine has a better view of the system requirements as a whole, which enables it to optimize the management of memory and threads. The end result is that SQL Server 2005 hosting the CLR in-process creates a more robust and scalable solution.

For example, consider a database instance that is heavily loaded, responding to many requests concurrently and over a long period. SQL Server can automatically and intelligently balance between allocation of memory to data stores versus program logic (for example, .NET stored procedures). When the load on the system changes in some qualitative way—for example, relatively more requests utilize more application logic—SQL Server can re-balance automatically. The performance of the system is continually optimized for real-world scalability and reliability. Because DB2 UDB v8.2 hosts the .NET runtime “out of process,” DB2 is not able to provide this sort of optimization and dynamic balancing of machine resources.

The CLR hosting APIs used by SQL Server 2005 to perform this dynamic optimization are available in version 2.0 of the .NET Framework, but they are not present in earlier versions of the .NET Framework. As a result, SQL Server 2005 requires the .NET Framework 2.0 while DB2 with its lower level of integration utilizes version 1.1 of the .NET Framework.

Differences Between .NET 2.0 and .NET 1.1 Using the .NET Framework 2.0 provides the combination of SQL server 2005 and Visual Studio 2005, offering some significant advantages over the .NET Framework 1.1 that’s used with DB2 UDB 8.2. The .NET Framework 2.0 has a number of significant enhancements including:

• Improved performance and load time

• Support for Generics (classes and methods that work uniformly on values of different types, thereby improving code reuse)

• Edit-and-Continue support that enables changing during execution without requiring a full recompilation

• A new Data Protection API (DPAPI) enables application to encrypt sensitive information like connection strings and even blocks of memory

• The authenticated streams feature uses the new NegotiateStream and SslStream classes to secure information sent between a client and a server

• COM Interoperability improvements give .NET applications better performance and more reliability when calling existing COM objects

• Improved I/O support plus support for GZIP data compression

• 64-bit application compatibility

Deploying .NET Logic to SQL Server The way in which each database platform actually uses the .NET objects is also quite different. With SQL Server 2005, a new SQL Server database object called an assembly is the unit of deployment for .NET artifacts, such as triggers or stored procedures, with the database. Assemblies are a unit of deployment for .NET logic. To create CLR database objects you must first create a DLL using Visual Studio 2005. Then that DLL is imported to SQL Server as a database assembly object. These steps can be performed manually, using command-line compilers and the CREATE ASSEMBLY command, or as you’ll see in the Detailed Walkthrough section, Visual Studio 2005 can automate this entire process.

Securing Assemblies in SQL Server For SQL Server 2005, the database assembly provides a new unit of security for the database administrator. Assemblies can be marked in one of three security types: SAFE, EXTERNAL, or UNSAFE. These security designations enable the database administrator to manage and secure all of the .NET code that runs inside the database at the assembly level. The SAFE designation indicates that the assembly only uses managed code and it accesses no resources outside the database. The EXTERNAL designation is used for managed code that accesses external resources such as the file system or the network in addition to database resources. The UNSAFE designation applies to assemblies that can contain managed and/or unmanaged code and that have the ability to access any internal or external resources. Database objects that are created using UNSAFE assemblies can only be executed by users who have systems administrator rights.

Deploying .NET Logic to DB2 Although the process for incorporating .NET managed code into DB2 UDB 8.2 is similar to SQL Server 2005, there are differences in database object types and locations, as well as security and database management processes. To create CLR database objects in DB2, you first create a DLL in a .NET managed language using Visual Studio. This DLL file must be copied to a special, well-known directory of the DB2 install path or the full path name needs to be given when the procedure or function is created. The DLL is not actually a database object or imported to a database table. Instead, it is a file in the operating system. The DLL is then used as part of the CREATE command to be used in the creation of a database object like a stored procedure or function. You’ll see in the Detailed Walkthrough that Visual Studio 2003 can automate the process of creating a CLR stored procedure for DB2, however, user defined functions are different. You will have to manually perform the process of creating a user defined function.

A database administrator or application developer may protect the DLL assemblies that are associated with the DB2 external routines by restricting the actions of the routines at run time. This is done using the EXECUTION CONTROL clause in the CREATE statement for the procedure or function. The valid execution control modes are: SAFE, FILEREAD, FILEWRITE, NETWORK, and UNSAFE. If the execution control mode is not specified, the default mode is SAFE, which means that the CLR routines can only access resources that are controlled by the database manager. Such resources would include all tables and schema managed by the database instance. The FILEREAD, FILEWRITE, and NETWORK execution modes allow the managed code to access resources on the local file system or network. The UNSAFE execution mode places no restrictions on resource access and routines with UNSAFE execution mode may execute binary code. Since DB2’s .NET integration is “out-of-process,” DB2 CLR procedures and functions must also use the FENCED clause in their CREATE statements to specify that the .NET logic runs in a different process than the database manager and does not use shared memory for communication. This results in a performance penalty when transferring data between program logic and the database itself, as compared to an in-process model.

Visual Studio and SQL Server 2005 Integration Visual Studio 2005 and SQL Server 2005 provide the highest level of integration that a Microsoft development environment has ever had with a database platform. SQL Server 2005 and Visual Studio 2005 provide unprecedented integration between database and development tool. Visual Studio 2005 delivers many database-specific features that can be used to develop SQL Server solutions. Some of these features, like the Server Explorer, can be used for both client and server-side database development projects. Others, like the SQL Server Project template and CLR item templates, are only used to develop SQL Server server-side artifacts. Figure 2 illustrates many of the database integration features that are present in Visual Studio 2005.

Figure 2 – SQL Server 2005 and Visual Studio

• Server Explorer. Server Explorer enables developers to browse and interact with server-side resources such as queues, databases, Active Directory, and others. Specifically for SQL Server 2005, the Server Explorer allows developers to browse both the metadata and data of a defined data source. The Server Explorer’s Data Connections view lists the tables, views, stored procedures, functions, synonyms, and assemblies that are found in the target data source. In addition, the Server Explorer enables you to access a number of database-specific features that you can see in Figure 2, including a graphical query designer, a table designer, the SQL query window, and a table data viewer.

• SQL Server Project Template. Enabling the creation of SQL Server CLR projects, the new SQL Server project template is invoked using the File menu and then selecting the New option followed by the Project option. This project type is supported for C#, Visual Basic, J#, and managed C++ projects. Every new SQL Server project automatically includes a reference to the sqlaccess.dll, which contains the in-process SQL Server .NET Data Provider. After a SQL Server Project is created, a number of SQL Server-specific Item templates are automatically added to your Visual Studio project.

• Stored Procedure Item Template. The Stored Procedure item template is used to create a CLR stored procedure. It automatically adds a class file to the project that contains the .NET stored procedure code.

• User-Defined Function Item Template. The User-Defined Function item template is used to create a CLR stored procedure. It automatically adds a class file to the project to contain the .NET stored procedure code.

• Trigger Item Template. The Trigger item template is used to create a CLR trigger. A class file is added to the project that contains the trigger stub code.

• Aggregate Item Template. The Aggregate item template is used to create a user defined aggregate. A class file is added to the project that contains the CLR aggregate stub code.

• Create New SQL Server Database. Started from the Tools menu, the Create SQL Server Database option displays a set of dialogs that enable you to create a new database on the target SQL Server system.

• Test Script Generation. Like its name suggests, the Test Script Generation feature creates scripts that can be used to test CLR stored procedures and functions created in Visual Studio. By default, the test scripts that are generated are stub files whose primary purpose is to provide a simple wrapper that can be used to invoke the routine. However, you can freely customize these scripts and add test data and other implementation-specific functionality.

• SQL/CLR Debugging. This feature enables you to seamlessly debug CLR stored procedures from Visual Studio 2005. The SQL/CLR debugger enables you to step in and out of both CLR and SQL code, and you can set breakpoints as well as inspect and change variables values. More information about debugging SQL Server CLR projects is shown in the Detailed Walkthrough section.

• Additional Project Types. In addition to the CLR-specific project types, Visual Studio 2005 also supports the development of projects for all of the other SQL Server development and management frameworks including System Management Objects (SMO), Replication Management Objects (RMO), Analysis Management Objects (AMO), and the Integration Services class library.

Visual Studio and DB2 UDB 8.2 Integration Installing the DB2 Application Development Client v8.2 on a machine that already has Visual Studio installed will configure DB2 Development Add-Ins into the Visual Studio .NET development environment. These add-ins provide Visual Studio 2003 with a collection of features that allow you to work with DB2 servers and develop DB2 procedures and functions. Some of these features, like the IBM Explorer, let you graphically create and manage data connections. You can launch the various DB2 development and administration tools from the DB2 Tools toolbar that is added to the Visual Studio main menu. You may also create and control DB2 projects from the Solution Explorer window. Figure 3 shows an overview of the DB2 Application Development Client features that are exposed within Visual Studio.

Figure 3 - DB2 UDB 8.2 and Visual Studio

• IBM Explorer. The IBM Explorer is a dockable window that is similar to the built-in Server Explorer provided by Visual Studio. The IBM Explorer’s Data Connections view lists the tables, views, procedures, functions, and data adapters of DB2 resources, whether local or remote. In addition, the IBM Explorer enables you to access a number of database-specific features such as a table designer and table data viewer.

• DB2 Database Project Template. Enabling the creation of DB2 CLR database projects, the new DB2 Database project template is invoked by selecting the File menu, then selecting New, and then selecting the Project menu option. The DB2 Database Project helps in the creation and management of DB2 database server scripts in the Solution Explorer.

• DB2 Class Library Project Template. This project type enables the creation and management of procedures and user defined functions and is supported for C# and Visual Basic projects. Creating a new DB2 class library project automatically adds a reference to the IBM.Data.DB2 data provider. A DB2 Class Library Template is not provided for J# or C++, so you need to manually code the data provider reference and DB2 objects into these class libraries.

• Stored Procedure Item Template. The Stored Procedure item template is used to create a DB2 CLR stored procedure from a DLL assembly included in your project. A wizard steps you through the selection of a DLL assembly and setup of the stored procedure’s parameters and actions. When the wizard is completed, a class file is automatically added to the project that contains the .NET stored procedure code.

• The DB2 Tools toolbar. This toolbar is integrated with the Visual Studio toolbars and it allows you to launch the external DB2 development and administration tools. The DB2 Tools toolbar includes: the Development Center, the Control Center, the Replication Center, the Command Center, the Task Center, the Health Center, the Journal, and the Information Center.

Manageability and Performance The primary management tool for SQL Server 2005 is the new SQL Server Management Studio. Shown in Figure 4, the new SQL Server Management Studio incorporates most of the functionality that used to be provided by SQL Server Enterprise Manager and Query Analyzer. It allows you to browse the server and database metadata as well as write and execute T-SQL queries.

Figure 4 – The SQL Server Management Studio

The SQL Server Management Studio is built using a specialized version of the Visual Studio 2005 IDE (Interactive Development Environment). Like Visual Studio 2005, the SQL Server Management Studio supports the creating software projects. It allows you to write, edit, run, and debug code. However, instead of working with .NET code, the SQL Server Management Studio is used to write T-SQL, MDX, DMX, and XMLA queries. It is also integrated with Visual SourceSafe for source code version control. The Object

Explorer window enables you to work with the database objects in each server. And the Solutions Explorer window enables you to group your database source code into logical collections.

SQL Server 2005 provides several performance tools that are both integrated into the operating system as well as into the management toolset. When SQL Server is installed, a collection of SQL Server-related performance counters is automatically added to the system. You can query these counters using System Monitor or via scripting with WMI. To help you fine tune your database queries, the SQL Server Management Studio supports returning both the actual and the estimated execution plan that’s used by any query that’s executed using the Query Editor. In addition, the integrated SQL Trace facility enables you to trace the execution of both database queries as well as Analysis servers queries.

DB2 UDB 8.2 allows you to manage and administer systems, DB2 UDB instances, databases, and database objects from a stand-alone application called the Control Center. The DB2 UDB 8.2 Control Center is shown in Figure 5.

Figure 5 – The DB2 UDB 8.2 Control Center

The Control Center allows for three different views of the DB2 database: Basic, Advanced, and Custom. The Basic view includes only the essential objects like the database, tables, and stored procedures. The Advanced view shows all objects and views available in the Control Center. The Custom view allows you create your own individualized view of the databases and their objects.

DB2 UDB 8.2 Control Center’s integrated Development Center application enables you to build stored procedures and functions and group them into projects. The stored procedures and user-defined functions created with the Development Center are built in SQL and not with .NET code. The Development Center does not provide source control.

Upon DB2 UDB 8.2 installation, performance counters are added to the system and may be queried using System Monitor or via scripting with WMI. DB2 UDB 8.2 provides several other monitoring tools, including a Query Patroller Center that can estimate the cost of running a query as well as control the workload of a set of queries running against a database.

Technical Walkthrough To enable you to get a deeper understanding of the differences in the Visual Studio integration of SQL Server 2005 and UDB 8.2, this next section takes you through the steps required to build a stored procedure using each of the different database products. First, we’ll present the code for a sample stored procedure that is written in C#. Then we’ll walk you through the process of creating and deploying that .NET stored procedure. The first example uses the combination of Visual Studio and SQL Server 2005 and the second example illustrates the same process using Visual Studio and UDB 8.2. As we go through this process, we’ll note the significant differences between the two products implementation details as well as dig deeper into other relevant integration details like the ability to debug the .NET code and secure the database objects that are created.

Description of SQL Server 2005 CLR Stored Procedure The ability to access external resources outside the database is one of the key advantages to using CLR database objects. Standard SQL and T-SQL statements can retrieve and manipulate relational data from the server but they are not capable of accessing system resources outside of the database such as the file system or the registry. CLR stored procedures (and other server-side artifacts coded in .NET) have full access to the .NET Framework. They can access relational data from the database engine as well as access external resources. An example stored procedure coded in C# is shown below. This stored procedure, named usp_ReadTextFile, reads data from a text file stored in the server’s filesystem into a SqlString data type.

using System; using System.Data; using System.Data.Sql; using System.Data.SqlServer; using System.Data.SqlTypes; using System.IO; public partial class StoredProcedures { [SqlProcedure] public static void usp_ReadTextFile(string sInputFile, out SqlString sColumn) {

string strContents; sColumn = ""; try { StreamReader strReader = new StreamReader(sInputFile); strContents = strReader.ReadToEnd(); strReader.Close(); sColumn = strContents; } catch (Exception ex) { SqlPipe sp = SqlContext.GetPipe(); sp.Send(ex.Message); } } }

First, examine the using statements. These enable the program logic to use the classes in the SQL Server .NET Data Provider’s namespace without needing to reference the fully qualified names of the classes. The SQL .NET Data Provider (under the namespace System.Data.SqlServer) is responsible for connecting to the SQL Server system.

The second thing to notice is the [SqlProcedure] attribute that precedes the method name. This attribute tells the .NET compiler and runtime this method will be exposed as a SQL Server stored procedure. Next, you can see that the default class name for this stored procedure is set to StoredProcedures. This class contains a static method named usp_ReadTextFile. When you are using C#, the method must be defined as static. For Visual Basic code, the method would need to be defined as Shared. The usp_ReadTextFile method accepts two parameters. The first parameter is an input parameter that passes in a string value that is used to supply the name of an operating system file. The second parameter is an output parameter (denoted by the out qualifier keyword). This parameter returns the contents of the text file to the caller as a SQLString data type which maps to a T-SQL varchar data type.

For those that cannot read C# code, here’s a quick summary of what this routine does: The code here essentially opens a text file, reads its contents, and places the contents in the SqlString output parameter. In the beginning of the procedure, a string variable is declared that will store the contents of the text file. Next, the file is read within the try-catch loop. First a StreamReader object named strReader is created and passed the name of the input file contained in the sInputFile variable. Then the StreamReader’s ReadtoEnd method is used to read the entire contents of the input file assigning them to the strContents variable. After the file has been read, the StreamReader is closed and the input data is moved to the sColumn output parameter.

If an error is encountered while attempting to read the input file, the code in the catch block will be executed. Here, an instance of the SqlPipe object is used to send an error message back to the caller of the procedure. First, an instance of the SqlPipe object named sp is created using the SqlContext.GetPipe method. Then the SqlPipe object’s Send method is used to pipe the contents of the ex Exception object’s Message property to the program that called the usp_ReadTextFile stored procedure.

To deploy this code into SQL Server, there are two steps: compilation and installation. The developer can perform these steps manually, by moving the assembly DLL and running SQL Server commands, or he can use Visual Studio to automate the task. To do it manually, copy the resulting assembly to a file system that’s accessible by SQL Server

and then run the CREATE ASSEMBY and CREATE PROCEDURE commands. However, if you're developing in Visual Studio 2005, then you simply select Build then Deploy Solution option to install the new CLR stored procedure in the SQL Server database. In the next section, we’ll walk through the steps of creating and deploying the usp_ReadTextFile CLR stored procedure using Visual Studio 2005.

Building a Stored Procedure with SQL Server and Visual Studio 2005 The following table summarizes the steps needed to create and deploy a CLR stored procedure to a SQL Server 2005 database using Visual Studio 2005.

Summary of Steps in Development Process Step Description Tool

1 Create new Visual Studio SQL Server Project Visual Studio 2005 File menu

2 Create Database Connection SQL Server Project Template

3 Add Stored Procedure Stored Procedure Project Template

4 Build Project Visual Studio 2005

Build menu

5 Deploy Project Visual Studio 2005

Build menu

Total 5 steps

Tools Integration To create a CLR stored procedure in Visual Studio 2005, you first create a SQL Server project by opening Visual Studio 2005 and from the File menu choosing the New Project menu option which will display the New Project dialog. On the New Project dialog you select SQL Server Project from the list of installed Visual Studio templates and give your project a name. The name used here will be the name of your Visual Studio solution. It will also be the name of the assembly that will be created. This can be the same name as your stored procedure if you have only a single stored procedure in the project, or it can be a different name if you want multiple stored procedures or other CLR database objects as part of the project.

Figure 6 – Creating a new SQL Server Project

Clicking the OK button will create the new project in the Visual Studio 2005 IDE and the SQL Server Project template will then automatically prompt you for your SQL Server 2005 database connection information. Visual Studio uses this information for debugging and deploying your solution. Typically, this initially is a development database; the .NET logic artifacts can be deployed to a production instance of SQL Server after testing and QA.

Figure 7 – Specifying the SQL Server project’s database connection properties

In the Connection Properties dialog box you can enter the name of your SQL Server system in the Select or enter a server name dropdown box. If you have multiple SQL Server systems registered on your development system, all of the registered system names will be listed when you click the dropdown arrow. If your target system is not listed you can also manually enter the system name or ID address in the dropdown box.

After you select the server, you next need to select the type of authentication that you want to use to connect to the server system. Selecting Windows NT Integrated Security will pass the user ID and password that you used in your Windows login to SQL Server. If your server is not set to use integrated security you can supply a SQL Server login using the User ID and Password prompts.

Next, select the database that you want to use as your deployment target. Click on the dropdown box to display a list of all of the databases that you are authorized to access. The database must exist on the SQL Server prior to creating your SQL Server project using Visual Studio 2005.

Once you’ve entered all of the required connection information you can test the connection by clicking the Test Connection button. If all of the connection information is valid a Successful Connection message will be displayed, otherwise you must correct the connection information. Clicking the OK button writes the connection information to the

Visual Studio project and displays the Visual Studio IDE. Because the connection information is persisted in the project it’s best to use integrated security which doesn’t store the actual login information. If you do explicitly provide the login information then you need to be sure that your project is stored in a secure location.

Figure 8 – The newly created SQL Server project

The SQL Server project that’s created is initially an empty solution. The Solution Explorer shows the name of the project that was carried over from the first New Project dialog box. In addition, the appropriate Reference files are automatically added to the project. In particular, the sqlaccess Reference is the system DLL that contains the SQL Server .NET Provider and the code required to create and execute .NET database objects.

To create a CLR stored procedure in Visual Studio 2005, from Visual Studio 2005’s Project menu, select Add Stored Procedure.

Figure 9 – Adding a CLR Stored Procedure

Here again, you can see the deep integration of SQL Server and the Visual Studio 2005 IDE. Options to create all of the different .NET database objects are present on the Visual Studio Project menu. In addition, you can also display options to create the different .NET database objects by right-clicking on the project in the Solution Explorer window and selecting the Add Item option. In either case this will display the Add New Item dialog box that you can see in Figure 10.

Figure 10 – Selecting the Stored Procedure item template

From the Add New Item dialog box, select the Stored Procedure option from the list of templates displayed in the Templates list and then provide the name of the stored procedure in the Name field that you can see near the bottom of the screen. Figure 10 shows that the stored procedure will be named usp_ReadTextFile. Click Add and Visual Studio 2005 will add a new class to your project for the stored procedure. Figure 11 shows the generated class file named after your stored procedure name. This class will include all of the required using directives as well as skeleton code that names the stored procedure. The default class name is set to StoredProcedures and within that class the skeleton for usp_ReadTextFile method is created, and prefixed with the previously mentioned [SqlProcedure] attribute. It's up to you to fill in the implementation.

Figure 11 – The generated SQL Server stored procedure class

After you’ve finished coding the stored procedure, you build exactly like any other C# project by selecting Build Solution from Visual Studio’s Build menu (Figure 12).

Figure 12 – Building the SQL Server CLR stored procedure

Building the project compiles it into an assembly on the local machine. In this example, that assembly is named usp_ReadTextFile.DLL. At this point, you must deploy the project by clicking the Build menu then selecting the Deploy Solution menu option to create the procedure on the SQL Server system.

Figure 13 – Deploying the stored procedure DLL to SQL Server

When you deploy the project, Visual Studio copies the assembly to the SQL Server database that was previously selected on the Connection dialog. Behind the scenes, it will run the CREATE ASSEMBLY and CREATE PROCEDURE statements to copy the usp_ReadTextFile.DLL assembly into the sys.assemblies table and then use that assembly to create the usp_ReadTextFile stored procedure.

Figure 14 – The deployment status

The output window at the bottom of the Visual Studio IDE shows the status of the deployment process. If the source code has been modified in any way, the deployment process will automatically recompile the assembly before deploying it to the SQL Server database. If the deployment succeeds, the “Deploy succeeded” message displays in the Visual Studio status bar.

After the CLR stored procedure has been deployed to SQL Server, the Visual studio integration features enable you to debug the procedure from the Visual Studio IDE. Before debugging the CLR stored procedure, you need to open the Server Explorer and right-click on the Data Connection that was built when the project was first created. Then from the pop-up menu select the Allow SQL/CLR Debugging option. Next, to debug the stored procedure, set a breakpoint in the .NET source code for the stored procedure and press F5 or click the green Run arrow icon. The test script for the stored procedure will run and the execution of the stored procedure will stop at the break point as is shown in Figure 15.

Figure 15 – Debugging SQL Server CLR stored procedures

From the debugger you can perform all of the same actions that you can normally perform when debugging normal Windows applications including displaying and changing the contents of variables as well as freely single-stepping between CLR and SQL code. This level of integration, where you can step in and out of both SQL code and .NET code has no parallel in DB2 UDB 8.2.

Description of a DB2 CLR Stored Procedure Much as they can with SQL Server, Visual Studio developers can build .NET logic for deployment into DB2 UDB v8.2.

DB2 CLR procedures have access to all of the functionality provided by the .NET Framework, just as with .NET logic running in SQL Server. However, there are differences between the DB2 UDB 8.2 implementation and the SQL Server implementation. These differences are outlined in the DB2 stored procedure presented in the next section.

To illustrate the basics, again we will use an example stored procedure that reads data from a text file into a String.

using System; using System.IO; using IBM.Data.DB2; namespace DB2ClassLibrary1 { /// <summary> /// This class and method is used for a DB2 CLR procedure. /// </summary> public class StoredProcedures { public static void usp_ReadTextFile( String sInputFile, ref String sColumn, out String sErrorMsg) { String strContents; try { StreamReader strReader = new StreamReader(sInputFile); strContents = strReader.ReadToEnd(); strReader.Close(); sColumn = strContents; sErrorMsg = null; } catch (Exception ex) { sErrorMsg = ex.Message; } } } }

The first point to note in this code is the directive that imports the IBM.Data.DB2 namespace. This enables the stored procedure to use the classes in the DB2 .NET Data Provider’s namespace without needing to reference the fully qualified name of the classes. Similar to the SQL .NET Data Provider, the DB2 .NET Data Provider is an extension of the .NET Framework and allows .NET applications to connect and execute commands to the DB2 system. The System.IO directive is also imported to allow access to the PC file directory.

The second thing to notice is the namespace DB2ClassLibrary1. The DB2 UDB Stored Procedure Template automatically creates the namespace for .NET projects. Next, you can see that the default class name for this stored procedure is set to StoredProcedures. This class contains a static method named usp_ReadTextFile.

Again, for those that cannot read C#, here’s a quick summary of the routine: The usp_ReadTextFile method uses three parameters. The first parameter is an input parameter that passes in a string value that is used to supply the name of an operating system file. The second parameter is an output parameter that returns the contents of the text file to the caller. The third parameter is an output parameter that returns any exceptions errors caught in the code. This parameter is required because DB2 does not contain an equivalent to the SqlPipe object which communicates with the procedure caller.

The rest of the code here is basically the same as the previously shown SQL Server code.

If an error is encountered while attempting to read the input file, the code in the catch block will be executed. In this example, the sErrorMsg parameter is set to the contents of the ex Exception object’s Message property, and returned to the program that called the usp_ReadTextFile stored procedure.

The next step is to build and deploy this stored procedure.

Building a Stored Procedure with DB2 and Visual Studio The following table captures the steps required to create the same usp_ReadTextFile stored procedure using Visual Studio and DB2 Stinger.

Summary of Steps in Development Process Step Description Tool

1 Create new Visual Studio DB2 Database Project Visual Studio File menu

2 Create Database Connection Visual Studio IBM Explorer pane

3 Add DB2 Class Library Visual Studio File menu

4 Build Assembly Visual Studio Build menu

5 Install Assembly Visual Studio Solution Explorer pane

6 Add Stored Procedure Visual Studio Stored Procedure Project Template

7 Build Solution Visual Studio Build menu

Total 7 steps

Tools Integration To create a CLR stored procedure in Visual Studio, you first create a DB2 Database Project by opening Visual Studio and selecting New and then choose Project… from the File menu, which will display the New Project dialog box. On the New Project dialog box you select IBM Projects from the Project Types list, and then select DB2 Database Project from the list of installed Visual Studio templates. You then give your project a name and designate a location to store your project. The name given here will be the name of your Visual Studio solution. As with SQL Server, this can be the same name as your stored procedure if you only have a single stored procedure in the project, or it can be a different name if you want multiple stored procedures or other CLR database objects as part of the project.

Figure 16 – Creating a new DB2 UDB Database Project

Click OK to create the new project in the Visual Studio IDE. You will notice in your Solution Explorer that the newly created DB2 Database Project contains folders for each of the database objects you may create using the Visual Studio IDE. The DB2 Data Connection dialog box will then be displayed with a dropdown box containing any previously defined DB2 connections. In this case, we have not yet set up any DB2 connections, so click New Connections to display the Add DB2 Data Connection dialog box (Figure 17).

Figure 17 – Create a new DB2 UDB database connection

On the Add DB2 Data Connection dialog box, enter the name of your DB2 system in the Server dropdown box. If you have multiple DB2 systems registered on your development system, all of the registered system names will be listed when you click the dropdown arrow.

After selecting the server, you continue setting up your connection by entering the database that you want to connect to in the Database alias dropdown box, and enter your user ID and password in the User name and Password prompts.

Once you’ve entered the required connection information you can test the connection by clicking Test Connection. If all of the connection information is valid, a Test connection succeeded message will be displayed. Click OK to write the connection information to the Visual Studio project and display the Visual Studio IDE. Again, if your project contains login information you should be sure that it is saved in a secure location.

The next step in creating a DB2 CLR stored procedure is to code the routine logic in any CLR-supported language. Our routine logic is written in a C# module, as described earlier. This C# class will be built into the assembly that will be used by the CLR. To add a C# class to your project, right-click your project solution in the Solution Explorer window and select Add then select New Project from the menu options. The Add New Projects dialog box is displayed. Select Visual C# Projects from the Project Types list,

and then select DB2 Class Library from the list of installed Visual Studio templates (Figure 18).

Figure 18 – Selecting the DB2 Class Library template

Enter a name for your class library and designate a location to store your library. Click OK. You will notice in your Solution Explorer window that the C# DB2ClassLibrary1 project has been added to your solution. The DB2ClassLibrary1 project contains references to the IBM.Data.DB2, System, System.Data, and System.XML namespaces. The DB2ClassLibrary project also includes an AssemblyInfo.cs file and a DB2Class1.cs file. The DB2Class1.cs contains a skeleton. At this point, you must add the implementation.

When you’ve finished coding the stored procedure, you build the class library project of the solution into an assembly by selecting Visual Studio’s Build menu, then select the Build DB2ClassLibrary1 option. Alternately, you may right-click the DB2ClassLibrary1 project from the Solution Explorer window and select the Build menu option.

Once the assembly is created, you need to install the assembly to the DB2 database. To install the assembly, right-click on the DB2DatabaseProject1 in your Solution Explorer window and select the Assemblies… menu option as you can see in Figure 19.

Figure 19 – Deploying the DB2 UDB Assembly

The CLR Assemblies dialog will then be displayed. In the File name textbox, select the DB2ClassLibrary1 DLL that was created in the previous step and click the Install button to install the assembly to the DB2 database.

Figure 20 – Installing the DB2 UDB Assembly

When an Installation of CLR Assembly Successful dialog is be displayed, click OK to continue on the next step; adding the CLR stored procedure.

After you have installed the assembly to the DB2 UDB database you can add a CLR stored procedure to DB2. To add the stored procedure to your project, click the Project menu, then select Add New Item…. The Add New Item – DB2DatabaseProject dialog box will be displayed, allowing you to select the CLR Procedure Wizard item from the available Visual Studio templates.

Figure 21 – Creating a new DB2 UDB CLR stored procedure

The DB2 CLR Procedure Wizard is then started. It steps you through creating a DB2 stored procedure that uses the generated .NET assembly. The CLR Procedure Wizard allows you to choose the assembly methods to consider for inclusion into the procedure script generation and optionally specify property values. Here you click through the wizard selecting methods, name and schema specifications, and SQL statements that you want automatically generated into the procedure script. This is quite different from the Visual Studio 2005/SQL Server 2005 implementation where code attributes identity the methods that will be used as stored procedures. The DB2 UDB methods of identifying the code methods using a Wizard introduces a disparity in the coding and deployment process which can introduce errors and is more labor intensive.

Figure 22 – Creating the CLR procedure script

When your choices have been made, click Finish to create the CLR procedure script. A DB2CLRProcedure.db2sp object is created in your project that includes the CREATE PROCEDURE statement needed to create the stored procedure in DB2.

Figure 23 – Building the DB2 UDB stored procedure

Lastly, you build the solution by selecting Visual Studio’s Build menu then select Build Solution. This compiles the DB2DatabaseProject and deploys it to the DB2 system you specified in the Data Connections. Note here that the Build Solution action automatically deploys the object to the database, which means there is no need for a separate deployment action.

There are no integrated debugging capabilities for the DB2 CLR stored procedure.

Summary Comparison of the Developer Experience

Area SQL Server DB2

Create Database Yes Yes

Browse Database data and metadata Yes (Server Explorer)

Yes (IBM Explorer)

Create Stored Procedure Yes – using template

Yes – using template

Selecting Methods to expose Attributes Wizard

Create Functions Yes – using template

Yes – manually

Create Triggers Yes – using template

No

Create User-Defined Types (UDTs) Yes – using template

No

Create Aggregates Yes – using template

No

Deploy CLR objects Yes – using Visual Studio 2005 menu options

Yes – using Visual Studio 2003 menu option

Debug CLR objects Yes – using Visual Studio 2005 Debugger

No

Beyond the Relational Database SQL Server 2005 provides a number of new features, which DB2 UDB has no parallel for, that extend beyond the bounds of a traditional relational database platform. SQL Server 2005 has the ability to function as an HTTP endpoint allowing it to process Web services requests without the need for any intermediate Web server like IIS. It also provides three new application enabling subsystems: the SQL Server Service Broker, SQL Server Notification Services and SQL Server Reporting Services.

HTTP Endpoints One of SQL Server 2005’s significant new features is the addition of native HTTP support to the database engine. This allows SQL Server to directly handle incoming Web services requests without the need for IIS or any other intermediate Web server. This enables SQL Server to provide dynamic SQL statement execution as well as stored procedure invocation via the SOAP protocol. The new HTTP endpoint support is compliant with the SOAP 1.0, 1.2 and WSDL 1.1 standards. SQL Server 2005’s new native HTTP support feature also supports both Windows and SQL Server authentication as well as SSL. For complete compatibility with the data tier programming layer, CLR stored procedure result sets can be returned as ADO.NET Datasets.

DB2 UDB 8.2 requires the use of an intermediate Web server to support Web services SOAP requests.

Service Broker The SQL Server Service Broker subsystem gives SQL Server 2005 support for developing applications that can exploit distributed database configurations for enhanced scalability. Asynchronous queuing is used to create highly scalable applications where the application services more requests that it would typically be able to handle in a serial fashion. Asynchronous support enables great application scalability because it allows a program to buffer requests during times of peak load, which allows more requests to be handled over the longer term. SQL Server 2005’s new SQL Service Broker subsystem provides guaranteed delivery of messages between SQL Server instances and is fully transactional. Like standard database transactions, transactions that incorporate queued events can be both committed and rolled back. Asynchronous queuing applications built using the SQL Service Broker can span multiple SQL Server systems and still provide guaranteed message delivery.

IBM DB2 UDB 8.2 doesn’t deliver a capability supporting asynchronous links between distributed instances of the database.

Notification Services Another new application development framework, SQL Server Notification Services, enables the database developer to build messaging applications that deliver selected information to multiple subscribers and devices. Notification Services was first introduced as a Web download for SQL Server 2000 and has since been incorporated as

a standard part of SQL Server 2005. For example, NYTimes.com uses Notification Services to alert interested parties of changes in real estate listings. SQL Server’s Notification Services scales well and includes end-user device support. SQL Server 2005's Notification Services gives you a big head start on this type of project by providing a robust, scalable, and tested framework that takes full advantage of the work that Microsoft has done to address these and other issues in building enterprise class notification applications.

IBM DB2 UDB lacks this capability.

Reporting Services One of the most important enhancements found in SQL Server 2005 that has no counterpart in any of the competing database platforms is Reporting Services. First introduced as an add-on for SQL Server 2000, the new SQL Server 2005 Reporting Services subsystem is fully integrated into SQL Server 2005. It is an enterprise-capable reporting system that provides the ability to visually construct reports as well as securely deploy those reports across the enterprise. SQL Server 2005’s Reporting Services is a server-based solution that can draw information from a wide range of common data sources including SQL Server, Oracle, DB2, and a variety of OLE DB and ODBC compliant databases. Reports generated by Reporting Services can be rendered in a variety of different formats including print outs, Web-based HTML reports, Windows-based rich client reports, as well as reports rendered for mobile devices.

IBM doesn’t provide a similar function in DB2. Customers would have to purchase a separate add-on reporting tool, at extra cost.

Integration Services SQL Server 2000 shipped with Data Transformation Services (DTS), a flexible set of tools and technologies for extracting and loading data.

With SQL Server 2005, DTS has been re-architected and gets a new name: Integration Services. Integration Services delivers better .NET integration, better performance, and more flexibility. Microsoft’s goal for Integration Services in SQL Server 2005 is to evolve it into an enterprise-capable Extraction Transformation and Loading (ETL) tool that delivers features and capabilities that are on par with any of the third-party standalone enterprise ETL products. Microsoft’s redesign of Integration Services gives it an all new architecture and toolset that provides better support for programmability and improved runtime performance. The new design clearly separates Integration Services’ data transfer and workflow capabilities, making it easier to create reuseable and scalable Integration Services packages. Like the older version, the new Integration Services uses OLE DB to connect to the data source and target, giving it the same flexibility that the original DTS possessed. Integration Services can transfer data between all of the major database platforms including SQL Server, Oracle, and DB2, but can also use Sybase, Excel files, MySQL, Active Directory, Firebird, and others as sources or destinations. SQL Server 2005 Integration Services features an all new graphical designer and a greatly expanded selection of native data transfer tasks and transformations.

With IBM’s DB2, customers need to purchase an extra-cost module to get similar ETL capability.

Analysis Services Since the release integrated OLAP Services with SQL Server 7, Microsoft has been the leader in the Business Intelligence (BI) space, changing OLAP from a niche technology and moving it into the database mainstream. BI enables an organization to get more meaningful information for planning and decision making by taking the operational data from line-of-business applications and using OLAP, data warehousing, and data mining technologies to summarize and query data in ways that are not possible with pure relational data access techniques. With SQL Server 2005, Analysis Services continues to be the leading integrated BI platform. Some of the primary enhancements to Analysis Services are found in the Analysis Services engine itself. With SQL Server 2005, Analysis Services is now able to support multiple instances. In addition, the installation process is now cluster-aware and Analysis Services can be seamlessly installed on failover clusters. Another significant change in the OLAP space for SQL Server 2005 is the introduction of the new Unified Dimensional Model (UDM). The UDM can be viewed as the next evolutionary step beyond OLAP cubes and it enables a unified reporting model by combining the best of OLAP and relational reporting capabilities.

With IBM’s DB2, customers need to purchase an extra-cost module to get similar OLAP capability.

Mobile Edition While each of the past releases of SQL Server have enjoyed tremendous enhancements in the area of upward scalability by its support for clustering with distributed partitioned views and 64-bit support, one of the often overlooked areas is SQL Server’s ability to scale down. SQL Server 2005 Mobile Edition extends enterprise data management to mobile devices. SQL Server 2005 Mobile Edition runs on the Windows CE platform and it brings relational database capabilities to the device level, providing an optimizing query processor, transaction support, native data types, and a device-level database access via the .NET Compact Framework. SQL Server 2005 Mobile Edition extends the reach of the SQL Server database platform by supporting remote data access and replication between the enterprise server and the device.

The IBM DB2 family includes a mobile version of the database, called DB2e. However, DB2e is a separately purchased product from DB2 UDB 8.2.

Conclusion The ability to integrate the CLR into the database has extended the power and flexibility of the database and makes it possible to move code between the database and the data tier for enterprise applications. CLR-database integration allows you to extend the built-in capabilities of the database platform by adding your own custom database objects that take advantage of the rich programmability of the .NET Framework allowing you to create more powerful database applications that are adaptable to changing circumstances.

While both SQL Server 2005 and DB2 UDB possess the ability to embed .NET logic in the database, SQL Server 2005 has several significant advantages over DB2 UDB 8.2. This paper showed that SQL Server 2005 provides both significantly wider and deeper integration with Visual Studio and the .NET Framework than DB2 UDB 8.2. SQL Server 2005’s wider support of the CLR is shown in its support for the creation of several additional database objects beyond the stored procedures and functions that are supported by DB2 UDB. Because SQL Server hosts the CLR “in process,” it’s deeper support for the CLR provides a more effective total solution, improving memory utilization, threading, and garbage collection capabilities of the CLR in ways that DB2’s external implementation does not allow. The Detailed Walkthrough illustrated the advantages that are present in SQL Server 2005’s tight integration with Visual Studio, enabling a seamless database object development, deployment, and debugging experience. In addition, beyond the relational database platform, SQL Server 2005’s Service Broker, Notification Services, Analysis Services, Integration Services, and Reporting Services subsystems provide an application development platform that extends beyond the capabilities offered by DB2 UDB 8.2.

About the Authors Michael Otey is Technical Director for Windows IT Pro Magazine and Senior Technical Editor for SQL Server Magazine. He is also President of TECA, Inc., a software development and consulting company that specializes in interoperability and database applications. Michael has worked with various version of DB2 since 1983. Michael is the author of the SQL Server 2005 New Features Guide published by Osborne McGraw Hill.

Denielle Otey is the Vice President of TECA, Inc., as well as a software consultant who has extensive experience designing, implementing, testing, and debugging software in C, VC++, VB, and Visual Studio .NET. She also is the developer of several SQL Server utilities, she has developed and delivered DB2 applications through TECA, Inc,, and she is co-author of ADO.NET The Complete Reference published by Osborne McGraw Hill.

This article was developed in partnership with A23 Consulting.