In recent years, Microsoft has been promoting a new software development platform for Windows, known as the .NET Framework. The .NET Framework is Microsoft’s replacement for Component Object Model (COM) technology. The following points highlight the key .NET Framework features:
- You can code .NET applications in over forty different programming languages. The most popular languages for .NET development are C# and Visual Basic .NET.
- The .NET Framework class library provides the building blocks with which you build .NET applications. This class library is language agnostic and provides interfaces to operating system and application services.
- Your .NET application (regardless of language) compiles into Intermediate Language (IL), a type of bytecode.
- The Common Language Runtime (CLR) is the heart of the .NET Framework, compiling the IL code on the fly, and then running it. In running the compiled IL code, the CLR activates objects, verifies their security clearance, allocates their memory, executes them, and cleans up their memory once execution is finished.
Through these features, the .NET Framework facilitates a wide variety of application implementations (for instance, Windows forms, web forms, and web services), rapid application development, and secure application deployment. COM and COM+ proved to be inadequate or cumbersome for all the aforementioned features.
The .NET Framework provides extensive data access support through ADO.NET. ADO.NET supports both connected and disconnected access. The key component of disconnected data access in ADO.NET is the DataSet class, instances of which act as a database cache that resides in your application’s memory. Connected access in ADO.NET requires no additional classes.
For both connected and disconnected access, your applications use databases through what’s known as a .NET data provider. Various database products include their own .NET data providers, including DB2 for Windows.
A .NET data provider features implementations of the following base classes:
Connection: Establishes and manages a database connection.
Command: Executes an SQL statement against a database.
DataReader: Reads and returns result set data from a database.
DataAdapter: Links a DataSet instance to a database. Through a DataAdapter instance, the DataSet can read and write database table data.
DB2 UDB for Windows includes three .NET data providers:
- DB2 .NET Data Provider: A high performance, managed ADO.NET data provider. This is the recommended .NET data provider for use with DB2 family databases. ADO.NET database access using the DB2 .NET Data Provider has fewer restrictions, and provides significantly better performance than the OLE DB and ODBC .NET bridge providers.
- OLE DB .NET Data Provider: A bridge provider that feeds ADO.NET requests to the IBM OLE DB Provider (by way of the COM interop module). This .NET data provider is not recommended for access to DB2 family databases. The DB2 .NET Data Provider is faster and more feature-rich.
- ODBC .NET Data Provider: A bridge provider that feeds ADO.NET requests to the IBM ODBC Driver. This .NET data provider is not recommended for access to DB2 family databases. The DB2 .NET Data Provider is faster and more feature-rich.
Supported .NET development software
To develop and deploy .NET applications that run against DB2® databases, you will need to use supported development software and operating systems.
Supported operating systems for developing and deploying .NET Framework 1.1 applications:
- Windows® 2000
- Windows XP (32-bit edition)
- Windows Server 2003 (32-bit edition)
Note: Windows 98, Windows ME, and Windows NT® are also supported, but only for running DB2 client-side applications.
Supported operating systems for developing and deploying .NET Framework 2.0 applications:
- Windows 2000, Service Pack 3
- Windows XP, Service Pack 2 (32-bit and 64-bit editions)
- Windows Server 2003 (32-bit and 64-bit editions)
Note: Windows 98 and Windows ME are also supported, but only for running DB2 client-side applications.
Supported development software for .NET Framework applications:
In addition to a DB2 client, you will need one of the following options to develop .NET Framework applications.
- Visual Studio 2003 (for .NET Framework 1.1 applications)
- Visual Studio 2005 (for .NET Framework 2.0 applications)
- .NET Framework 1.1 Software Development Kit and .NET Framework Version 1.1 Redistributable Package (for .NET Framework 1.1 applications)
- .NET Framework 2.0 Software Development Kit and .NET Framework Version 2.0 Redistributable Package (for .NET Framework 2.0 applications)
Supported deployment software for .NET Framework applications:
In addition to a DB2 client , you will need one of the following two options to deploy .NET Framework applications.
- .NET Framework Version 1.1 Redistributable Package (for .NET Framework 1.1 applications)
- .NET Framework Version 2.0 Redistributable Package (for .NET Framework 2.0 applications)
Setting up the Windows application development environment
When you install the DB2 Client on Windows operating systems, the install program updates the configuration registry with the environment variables INCLUDE, LIB, and PATH. The system-wide environment variable, DB2INSTANCE, is set by install to the default instance created, called DB2. DB2PATH is set inside a DB2 command window when the window is opened.
You can override these environment variables to set the values for the machine or the currently logged-on user. Exercise caution when changing these environment variables. Do not change the DB2PATH environment variable. DB2INSTANCE is defined as a system-level environment variable. You do not need to make use of the DB2INSTDEF DB2 registry variable which defines the default instance name to use if DB2INSTANCE is not set.
Procedure:
To override the environment variable settings, use the Windows Control Panel.
When using the variable %DB2PATH% in a command, put the full path in quotes, as in:
set LIB=“%DB2PATH%%\lib”;%LIB%
The default installation value for this variable is \Program Files\IBM\SQLLIB, which contains a space, so not using quotes can cause an error.
In addition, you must take the following specific steps for running DB2 applications:
When building C or C++ programs, you must ensure that the INCLUDE environment variable contains %DB2PATH%\INCLUDE as the first directory.
To do this, update the environment setup file for your compiler: Microsoft Visual C++ 6.0
"C:\Program Files\Microsoft Visual Studio\VC98\bin\vcvars32.bat"
Microsoft Visual C++ .NET
"C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\vsvars32.bat"
These files have the following commands:
Microsoft Visual C++ 6.0
set INCLUDE=%MSVCDir%\ATL\INCLUDE;%MSVCDir%\INCLUDE; %MSVCDir%\MFC\INCLUDE;%INCLUDE%
Microsoft Visual C++ .NET
@set INCLUDE=%MSVCDir%\ATLMFC\INCLUDE;...; %FrameworkSDKDir%\include;%INCLUDE% To use either file with DB2, first move %INCLUDE%, which sets the %DB2PATH%\INCLUDE path, from the end of the list to the beginning, as follows:
Microsoft Visual C++ 6.0
set INCLUDE=%INCLUDE%;%MSVCDir%\ATL\INCLUDE; %MSVCDir%\INCLUDE;%MSVCDir%\MFC\INCLUDE
Microsoft Visual C++ .NET
@set INCLUDE=%INCLUDE%;%MSVCDir%\ATLMFC\INCLUDE;...; %FrameworkSDKDir%\include
- When building Micro Focus COBOL programs, set the COBCPY environment variable to point to %DB2PATH%\INCLUDE\cobol_mf.
- When building IBM COBOL programs, set the SYSLIB environment variable to point to %DB2PATH%\INCLUDE\cobol_a.
- Ensure the LIB environment variable points to %DB2PATH%\lib by using: set LIB="%DB2PATH%\lib";%LIB%
Note: To enable cross-developing 64-bit applications from a 32-bit environment, see Migrating 32-bit database applications to run on 64-bit instances
Ensure that the DB2COMM environment variable is set at the server of a remote database.
Ensure that the security service has started at the server for SERVER authentication, and at the client, when using CLIENT authentication.
Note: Because CLIENT authentication happens on the client side instead of the server side, the client application is running under the context of the user. The Win32 authentication API requires certain privileges that might or might not be held by the user. In order to make sure that the CLIENT authentication takes place successfully, the authentication requests are passed from the client application to the security server (which runs under a privileged account local system by default, and has the right to call the authentication API).
To start the security service manually, use the NET START DB2NTSECSERVER command.
Normally, the only time you would want to set the security service to start automatically is if the workstation is acting as a DB2 client connecting to a server that is configured for Client Authentication. To have the security service start automatically, do the following:
Windows 2000 and Windows Server 2003
- Click the ″Start″ button.
- For Windows 2000, click ″Settings″ and then click ″Control Panel″. For Windows Server 2003, click ″Control Panel″.
- Click ″Administrative Tools″.
- Click ″Services″.
- In the Services window, highlight ″DB2 Security Server″.
- If it does not have the settings ″Started″ and ″Automatic″ listed, click ″Action″ from the top menu.
- Click ″Properties″.
- ake sure you are in the ″General″ tab.
- Choose ″Automatic″ from the ’Startup Type’ drop-down menu.
- Click ″OK″.
- Reboot your machine to have the settings take effect.
Windows XP
- Click the ″Start″ button.
- Click ″Settings″.
- Click ″Control Panel″.
- Click ″Performance and Maintenance″.
- Click ″Administrative Tools″.
- Click ″Services″.
- In the Services window, highlight ″DB2 Security Server″.
- If it does not have the settings ″Started″ and ″Automatic″ listed, click ″Action″ from the top menu.
- Click ″Properties″.
- Make sure you are in the ″General″ tab.
- Choose ″Automatic″ from the ’Startup Type’ drop-down menu.
- Click ″OK″.
- Reboot your machine to have the settings take effect.
The database manager on a Windows XP, Windows Server 2003,or a Windows 2000 environment is implemented as a service, and hence does not return errors or warnings when the service is started, though problems might have occurred. This means that when you run the db2start or the NET START command, no warnings will be returned if any communication subsystem failed to start. Therefore, the user should always examine the event logs or the DB2 Administration Notification log for any errors that might have occurred during the running of these commands.
If you will be using DB2 CLI or Java™, proceed to the appropriate task:
– Setting up the Windows CLI environment
– Setting up the Windows CLI environment
Related tasks:
- “Migrating 32-bit database applications to run on 64-bit instances” in Migration Guide
- “Setting up the Windows CLI environment” in Call Level Interface Guide and Reference, Volume 1
- “Installing the IBM DB2 Driver for JDBC and SQLJ” in Developing Java Applications
- “Configuring the operating system for database application development” in Getting Started with Database Application Development
- “Setting environment variables on Windows” in Administration Guide: Implementation
- “Setting the default instance when using multiple DB2 copies (Windows)” in Administration Guide: Implementation.
DB2 integration in Visual Studio
The IBM Database Add-Ins for Visual Studio 2003 and 2005 are a collection of features that integrate seamlessly into your Visual Studio development environment so that you can work with DB2 servers and develop DB2 procedures, functions, and objects. These add-ins are designed to present a simple interface to DB2 databases. For example, instead of using SQL, the creation of database objects can be done using wizards. And for situations where you do need to write SQL code, the integrated DB2 SQL editor has the following features:
- Colored SQL text for increased readability
- Integration with the Microsoft Visual Studio IntelliSense feature, which provides for intelligent auto-completion while you are typing DB2 scripts
With IBM Database Add-Ins for Visual Studio, you can:
- Open various DB2 development and administration tools
- Create and manage DB2 projects in the Solution Explorer
- Access and manage DB2 data connections (in Visual Studio 2005 you can do this from the Server Explorer; in Visual Studio 2003, you can do this from the IBM Explorer)
- Create and modify DB2 scripts, including scripts to create stored procedures, functions, tables, views, indexes, and triggers.
Visual Studio 2003
The IBM Database Add-Ins for Visual Studio 2003 are included with the DB2 Client and the DB2 servers. The DB2 installation detects the presence of Visual Studio 2003, and if it is installed, the add-ins are registered. If you install Visual Studio 2003 after you install a DB2 product, run the ″Register Visual Studio Add-Ins″ utility from the DB2 instance’s start menu.
Visual Studio 2005
The IBM Database Add-Ins for Visual Studio 2005 are included as a separately installable component with the DB2 Client and the DB2 servers. Once you are finished installing your DB2 product, you will be presented with an option to install the IBM Database Add-Ins for Visual Studio 2005. If you do not have Visual Studio 2005 installed on your computer, the add-ins will not install. Once you install Visual Studio 2005, you can then install the add-ins at any time from the DB2 product’s setup menu.