DB2 Database Project for Visual Studio .Net

Attention all you .NET developers! Take a tour of the DB2 database project for Visual Studio .NET and learn how easy it is to write, build, and configure database applications on DB2 with this integrated application development environment.

Share:

Abdul Al-Azzawe, DB2 Development Tools Architect, IBM San Francisco

Photo: Abdul H. Al-AzzaweAbdul H. Al-Azzawe is a senior software engineer at the IBM Silicon Valley Lab in San Jose. An IBM veteran, he joined the company in 1990. Abdul is the lead architect for the SQL debugger and the application development tools for DB2 on Windows. Prior to his current assignment, he was a member of the core DB2 engine development team at the IBM Toronto Lab.



24 April 2003

Also available in Chinese

Note from the editor: The IBM DB2 Development Add-Ins for Visual Studio .NET are available as part of DB2 V8.1.2 and later.

Introduction

The IBM DB2® Universal DatabaseTM Development Add-Ins for Visual Studio .Net is a set of tightly integrated application development and administration tools specifically designed for DB2 UDB. The DB2 database project template lets you use scripts for developing server-side objects, including stored procedures, user-defined functions (UDFs), tables, views, indexes and so on.

This article gives you a detailed overview of the new DB2 Database Project support in the Visual Studio .NET Solution Explorer.


Overview of the DB2 database project

The DB2 database project lets you develop server-side objects using scripts. These DB2 scripts may contain DB2 data definition language (DDL) and data manipulation language (DML) SQL statements. Using these scripts, you can create SQL stored procedures, SQL user-defined functions, tables, views, indexes, triggers, types, and so on.

With a DB2 database project, you can:

  • Add new or existing SQL stored procedure scripts.
  • Add new or existing SQL user-defined function (UDF) scripts.
  • Add new or existing scripts based on generic templates that contain supported DB2 data definition language (DDL) and data manipulation language (DML).
  • Specify project dependencies and project build order in the solution.
  • Specify build configuration options including script files build order.
  • Check your script files into any configured source control management system such as Microsoft® Visual Source Safe.

Adding a DB2 database project

You can add a DB2-specific database project to your Visual Studio solution using the Add New Project dialog. The IBM DB2 Development Add-Ins for Visual Studio.Net provides you with a new DB2 Database project under the IBM Projects folder.

Figure 1. DB2 database projects are under IBM Projects
DB2 database projects are under IBM Projects

The DB2 database project is a storage-based Visual Studio project. Each of the folders under the project maps to actual file system folders under the project folder. Each of the items under the project folders maps to one or more files.

Choosing a DB2 database reference for your projects

When you build a DB2 database project, the project script files are compiled. Compiling a script file means executing the DDL and DML script against a DB2 database reference that is defined for your project. You can elect to choose a different database reference in each project build configuration.

To choose a database reference, simply specify the DB2 data connection name in the Data Connection project property. If you click the [...] property button, the Data Connection dialog is launched, which lets you select an existing IBM Explorer connection or add a new one.

Figure 2. Connecting the project to a database
Connecting the project to a database

DB2 project items - scripts

For any Visual Studio project, you can add new or existing items using to a project. New items can be added directly under the project folder or any of the project subfolders.

All of the items in the DB2 project folders are DDL or DML script files. Although DB2 supports stored procedures and UDF in JavaTM and other languages, only SQL language routines are shown. This restriction only applies to scripts for creating such routines - you can still view and use these routines using the IBM Explorer.

There are three default folders in the DB2 database project: procedures, functions, and scripts. Additional folders may be added to the project. These folders serve to organize your project items, which are DB2 scripts. Entries under each of the project folders are DB2 script file names and do not necessarily map to any actual object names that may be created by the script file.

The DB2 database project items are in two categories:

  • Script template file entries that require no user input apart from the script file name to generate a default script file. These items include procedures, scalar and table functions, triggers, tables, table views, queries, and other generic DB2 scripts.
  • Script wizard entries that launch an interactive wizard for customizing and generating the script file. There include wizards for creating a SQL stored procedure and SQL UDFs. Additional functionally rich wizards are planned to be added over time.

You can also add your own item templates using the Add New Items dialog. This section describes:

Procedure scripts

The procedures folder of your DB2 database project can contain any script files that are used to create and managed DB2 SQL stored procedures. These script files typically contain DROP and CREATE statements, as well as GRANT permission statements.

The stored procedure script files have been separated from generic script files to allow you to specify additional stored procedure build options including z/OSTM and OS/390® advanced build and execution options such as the WLM environment option.

Figure 3. Adding a DB2 stored procedure to a DB2 database project
Adding a DB2 stored procedure to a DB2 database project

Procedure script template
If you choose the Create Stored Procedure project item template shown in Figure 3, a default DB2 create stored procedure script file is added to your project and is shown in the editor. The script drops and then creates a sample SQL stored procedure. You can modify the script to include additional supporting DDL such as granting access for the procedure, altering the procedure, and so on.

Listing 1. Default stored procedure script template

-- <ScriptOptions errors="off" platform390="off"/>
@ 
-- Drop the stored procedure if one already exists
DROP SPECIFIC PROCEDURE MySpecificSP 
@ 
COMMIT 
@ 
-- <ScriptOptions errors="on"/> 
@ 
-- Create stored procedure
CREATE PROCEDURE MyProcedure (  ) 
	SPECIFIC MySpecificSP 
	LANGUAGE SQL 
	DYNAMIC RESULT SETS 1 
----------------------------------------------------
---------------------- SQL Stored Procedure  
-------------------------------------------------------------------
P1: BEGIN 
-- Declare cursors
DECLARE DB2_SP_SQL1 
CURSOR WITH RETURN FOR  
	Select ROUTINENAME, ROUTINESCHEMA, 
	LANGUAGE from 
SYSIBM.SYSROUTINES; 
-- Cursor left open for client application.
	OPEN DB2_SP_SQL1; 
END P1 
@ 
-- Grant access privileges to stored procedure
GRANT EXECUTE ON SPECIFIC PROCEDURE
 MySpecificSP TO PUBLIC
@

Procedure script wizard
If you choose the Create Stored Procedure Wizard project item template, the DB2 SQL Stored Procedure wizard guides you through the steps required to customize the stored procedure body and script file according to your project requirements.

  1. Identification step - Specify the procedure name, schema, specific name and comment.
    Figure 4. DB2 SQL stored procedure wizard
    DB2 SQL stored procedure wizard
  2. SQL statements step - Create one or more SQL statements for the stored procedure.
  3. Parameters step - Specify parameters for the stored procedure.
  4. Code options step - Specify the files that contain code fragments that you want to insert in the generated stored procedure code. Also, specify the SQL error-handling code that you want to include in the stored procedure.
  5. Script options step - Specify files that contain script fragments that you want to insert in the generated stored procedure script. Also, specify additional SQL statements that you want to generate.
  6. Summary and show code step - Displays a summary of your options and the script file that will be generated.

Function scripts

The functions folder of your DB2 database project can contain any script files that are used to create and managed DB2 SQL UDFs. These script files typically contain DROP and CREATE statements, as well as GRANT permission statements.

Figure 5. Adding a UDF to a DB2 database project
Adding a UDF to a DB2 database project

Function script template
If you choose the Create User-Defined Function project item template, a default DB2 script file is added to your project and is shown in the editor. The script drops and then creates a sample SQL scalar UDF.

Listing 2. Default user-defined function script template

-- <ScriptOptions errors="off" platform390="off"/>
@ 
-- Drop the user-defined function if one already exists
DROP SPECIFIC FUNCTION MySpecificSUDF 
@ 
COMMIT 
@ 
-- <ScriptOptions errors="on"/>
@ 
-- Create scalar user defined function
CREATE FUNCTION MySUDF(DUMMY INTEGER) 
	SPECIFIC MySpecificSUDF 
	RETURNS INTEGER 
------------------------------------------------------
---------------------- DB2 SQL user-defined function - 
---------------------------------------------------------------------
F1: BEGIN ATOMIC 
	RETURN SELECT COUNT(*) 
	FROM SYSIBM.SYSTABLES 
	AS TABLES; 
END F1 
@ 
-- Grant access privileges to UDF
GRANT EXECUTE ON SPECIFIC FUNCTION
MySpecificSUDF TO PUBLIC 
@ 
 
 
-- <ScriptOptions errors="off"/>
@ 
-- Drop the user-defined function if one already exists
DROP SPECIFIC FUNCTION MySpecificTUDF 
@ 
COMMIT
@ 
-- <ScriptOptions errors="on"/>
@ 
-- Create table user-defined function 
CREATE FUNCTION MyTUDF(DUMMY INTEGER) 
	RETURNS TABLE(NAME VARCHAR(4000), CREATOR VARCHAR(4000), 
	TYPE  
	CHARACTER(254), CTIME TIMESTAMP) 
	SPECIFIC MySpecificTUDF 
-------------------------------------------------------
--------------------- DB2 SQL user-defined function - 
----------------------------------------------------------------------
F2: BEGIN ATOMIC 
	RETURN SELECT NAME, CREATOR, 
	TYPE, CTIME FROM SYSIBM.SYSTABLES; 
END F2 
@ 
-- Grant access privileges to UDF 
GRANT EXECUTE ON SPECIFIC FUNCTION 
MySpecificTUDF TO PUBLIC 
@

Function script wizard
If you choose the Create User-Defined Function Wizard project item template, the wizard will guide you through the steps required to customize the UDF body and script file according to your project requirements.

  1. Identification step - Specify the function name, schema, specific name, output type (table or scalar) and comment.
    Figure 6. Using a wizard to create a SQL UDF
    Using a wizard to create a SQL UDF
  2. SQL statements step - Create the scalar or tabular SQL query.
  3. UDF Return Data Type step - Select the scalar type or the set of table column name and types.
  4. Parameters step - Specify input parameters for the UDF.
  5. Code options step - Specify the files that contain code fragments that you want to insert in the generated UDF code. Also, specify the SQL error-handling code that you want to include in the UDF.
  6. Script options step - Specify files that contain script fragments that you want to insert in the generated UDF script. Also, specify additional SQL statements that you want to generate.
  7. Summary and show code step - Displays a summary of your options and shows you the DB2 script file that will be generated.

Generic scripts

Apart from supporting stored procedure and UDF scripts, the Add New Item lets you create generic DB2 script files that can contain any valid SQL statements. There are default templates for creating tables, views, triggers, and queries. These script files are added to your project and shown in the editor. You will need to modify the script file according to your project requirements.

Figure 7. Adding a script for a DB2 database project
Adding a script for a DB2 database project

Create table script template
Using the DB2 database project, you can create any number of DB2 tables and table indexes in a generic script file. If you choose the Create Table script file template, the following script file will be added to your project and shown in the editor:

Listing 3. Default table script template

-- <ScriptOptions errors="off"/>
@ 
-- Drop old version of table
DROP TABLE MyTable 
@ 
COMMIT
@ 
-- <ScriptOptions errors="on"/>
@ 
-- Create new version of table
CREATE TABLE MyTable 
 (ID           SMALLINT NOT NULL, 
 NAME         VARCHAR(9), 
 DEPT         SMALLINT CHECK DEPT BETWEEN 10 AND 100), 
  JOB          CHAR(5) CHECK (JOB IN ('Sales', 'Mgr', 'Clerk', 
  'Tech')), 
  HIREDATE     DATE, 
  SALARY        DECIMAL (7,2), 
  COMM         DECIMAL (7,2), 
  PRIMARY KEY  (ID)) 
@ 
-- <ScriptOptions platformLUW="off"/>  
@ 
-- Create primary key table index for z/OS  
 CREATE UNIQUE INDEX  MyTableIndex ON  MyTable(ID) 
@ 
-- <ScriptOptions platformLUW="on"/>  
@ 
-- <ScriptOptions displayGrid="off"/>  
@ 
-- Insert a new record  
 INSERT INTO   MyTable VALUES  (1,'John', 15, 'Mgr', '1990-01-01' ,  
40000.00, 1000.00) 
@ 
 INSERT INTO  MyTable VALUES  (2,'Smith', 15, 'Tech', '1995-12-10' ,  
25000.00, 1000.00) 
@ 
 INSERT INTO  MyTable VALUES (3,'James', 15, 'Sales', '1997-05-21' ,  
10000.00, 5000.00) 
@ 
-- <ScriptOptions displayGrid="on"/>  
@

The script drops and then creates a sample table. You can modify the script to include advanced table properties, such as table spaces, indexes, constraints, and referential integrity rules.

When this script file is compiled, the old version of the table is first dropped and the new one is created. Execution results are displayed in the output pane. The new table does not appear automatically in the IBM Explorer. Youl need to refresh the appropriate folder first.

Create view script template
Using the DB2 database project, you can create any number of DB2 table views in a generic script file. If you choose the Create View script file template, the following script file will be added to your project and shown in the editor:

Listing 4. Default view script template

-- <ScriptOptions errors="off"/>  
@ 
-- Drop old version of view  
 DROP VIEW  MyView; 
@ 
 COMMIT  
@ 
-- <ScriptOptions errors="on"/>  
@ 
-- Create new version of view  
 CREATE VIEW  MyView ( ID, NAME, DEPARTMENT) 
   AS SELECT ID, NAME, DEPT 
     FROM MyTable 
     WHERE MyTable.JOB = 'Mgr' 
@

When this script file is compiled, the old version of the view is first dropped and the new one is created. Execution results are displayed in the output pane. The new view does not appear automatically in the IBM Explorer until you refresh the appropriate folder.

Create trigger script template
Using the DB2 database project, you can create any number of DB2 table triggers in a generic script file. If you choose the Create Trigger script file template, the following script file will be added to your project and shown in the editor:

Listing 5. Default trigger script template

-- <ScriptOptions errors="off"/>  
@ 
-- Drop the trigger if one already exists  
DROP TRIGGER  MyTrigg 
@ 
COMMIT  
@ 
-- <ScriptOptions errors="on"/>  
@ 
-- Create trigger  
CREATE TRIGGER  MyTrigg 
	AFTER INSERT ON MyTable 
    REFERENCING NEW AS N_ROW 
	FOR EACH ROW MODE DB2SQL 
	WHEN (N_ROW.JOB = 'Mgr') 
BEGIN ATOMIC 
	UPDATE MyTable 
	   SET COMM  = 
	   COMM + 500.00 
	 WHERE MyTable.
	 ID = N_ROW.
	 ID; 
END  
@

The script drops and then creates a sample trigger. Multiple triggers may be defined in the same script file.

When this script file is compiled, the old version of the trigger is first dropped and the new one is created. Execution results are displayed in the output pane.

Create query script template
Using the DB2 database project, you can create any number of DB2 queries in a generic script file. If you choose the Create Query script file template, the following script file will be added to your project and shown in the editor:

Listing 6. Default query script template

-- <ScriptOptions displayGrid="off"/>  
@ 
-- Insert a new record  
INSERT INTO  MyTable 
VALUES (4,'Jeff', 15, 'Mgr', '1997-02-21' ,  
40000.00, 1000.00) 
@ 
INSERT INTO  MyTable 
VALUES (5,'Nora', 15, 'Tech', '1999-03-01' ,  
25000.00, 1000.00) 
@ 
INSERT INTO  MyTable 
VALUE (6,'Derek', 15, 'Sales', '2000-01-01' ,  
10000.00, 5000.00) 
@ 
-- <ScriptOptions displayGrid="on"/>  
@ 
-- Some queries  
SELECT  * 
FROM  MyTable 
@ 
SELECT  * 
FROM  MyView 
@

When this script file is compiled, the query results are displayed in the output pane.

Script template
The generic script template is a blank script file. You can code any supported SQL statementsin these script files. This is useful for developing applications. For example, you may have a project in which not only must tables be created, but data must be loaded as well. You can achieve this by coding the SQL load statement in a generic script that would load data from a text item that is added to the project in a generic project folder.


Advanced scripting and script options

The DB2 Development Add-In for Visual Studio .NET provides you with a functionally rich scripting engine that goes above and beyond the creation of database server-side objects. You can also create custom scripts that use advanced scripting options to better meet your project requirements.

Test scripts

Using the generic script template, you can create a script file that tests the various database elements created by your DB2 project. For example, you could create a test script that creates a temporary table, populates it with test data, invokes a project stored procedure that operates on this table, passes in any required input parameters, and then cleans up and rolls back the transaction. This script can thus be used to test the functionality of the stored procedure.

Do not include these scripts in the project build; they typically reside in their own test DB2 database project.

Scripts and database transactions

By default, each script is executed as one unit of work. A new transaction is created at the start of a script file compilation. The transaction is committed at the end of the script file compilation if no errors were encountered. When an error is encountered during the compilation, the script execution ends and the transaction rolls back.

You can also embed your own set of COMMIT or ROLLBACK statements in the script file if you need to control transactions at a more granular level than a script file.

Advanced script options

The DB2 database project script files support a special XML tag that allows for defining script execution options. The special XML tag is preceded by the standard DB2 comment delimiter, namely, a double dash (--). The XML tag for this script option is <ScriptOptions>.

Ignoring errors option
When an error is encountered when a script file executes, the compilation step is halted. This may not be desirable in certain cases where the error is really a warning, allowing for the script execution to continue. One example would be a DROP SPECIFIC PROCEDURE statement before a CREATE PROCEDURE statement. The drop is there to ensure that the script can be built multiple times and that the older version of the procedure is deleted. This drop will fail the first time the script is executed because the procedure has not been created yet.

To treat errors as warnings, set the value of the errors script options property to "off". To revert back to the default behavior of treating errors as failures, set the property value to"on".

Listing 7. Script fragment demonstrating use of error handling option

-- <ScriptOptions errors="off"/>  
@ 
-- Drop the stored procedure if one already exists
  
DROP SPECIFIC PROCEDURE MySchema.MySpecificSP 
@ 
-- <ScriptOptions errors="on"/>  
@

Data grid output option
For any database operation performed during a script file execution that results in a data set, the data set is displayed in an output data grid as well as in the IBM DB2 Development Add-In output view as XML.

Although this may be very desirable, especially for viewing results from executing test scripts, it is not always required. One example would be to avoid displaying results from an SQL insert statement, where displaying the resulting number of rows inserted in the output pane is sufficient.

To disable displaying data sets resulting from script execution in a data grid, set the value of the displayGrid script options property to "off". To revert back to the default behavior, set the property value to "on".

Listing 8. Script fragment demonstrating use of displayGrid display option

-- <ScriptOptions displayGrid="off"/>  
@ 
-- Insert one record into the table  
INSERT INTO  MySchema.MyTable VALUES  (1,'Kreg', 15, 'Mgr', '1990-01-01' ,  
40000.00, 1000.00) 
@ 
-- <ScriptOptions displayGrid="on"/>  
@

Statement separator option
In most cases, your database project scripts will contain more than one SQL statement. These statements must be separated by a character delimiter. The default character delimiter is the '@' character. This default may be modified by directly accessing the userOptions.xml file or by using Tools -> Options -> IBM DB2 Tools.

When the separator is specified, it should remain the same. To ensure this, the statementSeparator option is used to specify this value.

Listing 9. Script fragment demonstrating use of statementSeparator source option

-- <ScriptOptions statementSeparator="@"/>  
@

Platform restriction option
Although most of the DDL and DML in your scripts should abide by the DB2 family compatibility rules, there are situations where it would make sense to have platform-specific SQL statements. These statements should only be executed on specific DB2 platforms. One such example is the use of PRIMARY KEY clause in the CREATE TABLE statement. On Linux, UNIX®, and Windows®, DB2 will automatically create the required table index to enforce the key uniqueness. For z/OS, you must manually create the index. The platform restriction option will allow you to accomplish this using the same script file.

To disable executing statements on the Linux, UNIX, and Windows platforms, set the platformLUW script options property to "off". To revert back to the default behavior, set the property value to "on". For z/OS and OS/390, use the platform390 script option property.

Listing 10. Script fragment demonstrating use of platformLUW platform restriction option

-- <ScriptOptions platformLUW="off"/>  
@ 
-- Create primary key table index for z/OS  
CREATE UNIQUE INDEX MySchema.MyTableIndex ON  MySchema.MyTable(ID) 
@ 
-- <ScriptOptions platformLUW="on"/>  
@

Project configurations and properties

Although the standard Visual Studio database project does not support configurations, the DB2 Database project does. Every project in Visual Studio can support multiple build configurations. This feature is driven at a solution or project level. The list of solution configurations for a given solution is managed by the Solution Configurations dialog.

The ability to have multiple build configurations for a DB2 database project lets you choose different project database references, different SQL build options that are specific to a target database platform, different sets of script files that are to be compiled (executed) against that database connection, and so on.

The standard Visual Studio .NET properties grid with custom property value editors is used for managing project and project item properties.

Project properties

Each DB2 project has a set of configuration-independent (common) properties, as well as configuration-specific properties. Project properties include such things as default database reference (for script execution), database user name and password, and so on.

Note that configuration-specific properties will take precedence over common project properties; hence the ability to specify a different database connection per configuration.

Figure 8. Visual Studio .NET project configurations dialog for a DB2 database project
Visual Studio .NET project configurations dialog for a DB2 database project
Figure 9. Visual Studio .NET project properties for a DB2 database project
Visual Studio .NET project properties for a DB2 database project

Item properties

Each DB2 project item will have a set of configuration-specific properties, as well as configuration-independent properties.

Configuration-specific properties take precedence over common properties; hence the ability to specify different database build options per configuration.

Figure 10. Configuring-specific properties for a DB2 stored procedure
Configuring-specific properties for a DB2 stored procedure

Configuration-independent properties are divided into two groups: source-based and designer-based. Source-based properties are parsed from the actual script file for the object (such as procedure name and schema). Parsing occurs when a file is opened or saved. Designer-based properties are not defined in the source (such as the z/OS build options).

Figure 11. Configuration-independent properties for a DB2 stored procedure
Configuration-independent properties for a DB2 stored procedure

Persisting properties
For DB2 projects, a project's common and configuration-specific properties are persisted in an XML project file.

For DB2 project items, configuration-specific properties are persisted in the project file, but common properties (script-based and designer-based) are persisted in an XML file that is associated with each of the project items. This implementation has the advantage of always associating a project item with its properties, including the ability to check in these files into SCMs or including (that is, importing) them into other projects as existing items.

To illustrate this, consider the project item, procedure1. This item has a procedure1.db2sp script file and a procedure1.db2spx properties files (XML-based). Both procedure1.db2sp and procedure1.db2spx are treated as one item and are checked into and out of the source code management system together.

File extensions
The following table includes the set of file extensions that are supported by DB2 projects:

Table 1. DB2 Project items file extensions

Item typeScript extensionMetadata extension
Stored proceduresdb2spdb2spx
User-defined functionsdb2udfdb2udfx
Scriptsdb2db2x
MiscellaneousAny extensionNone!

Projects dependencies and build order

Like most other Visual Studio .NET project, DB2 database projects participate in the solution project dependencies and build order.

Project dependencies

Using the Dependencies folder of the Project Dependencies dialog, you can specify cross-project dependencies. This is a very useful and powerful feature. You can envision a situation where a DB2 functional test project would depend on another DB2 project that will actually create the set of DB2 objects that will be tested by the test project. Taking this further, it is possible for a Web services C# project to have a dependency on a DB2 project that creates a set of SQL stored procedures that needs to be surfaced as Web services.

Figure 12. Showing cross-product dependencies
Showing cross-product dependencies

Project build order

The Build Order tab of the Project Dependencies dialog shows you the resulting projects build order based on the set of project dependencies specified in the Dependencies dialog. When you execute a solution build command, the projects in the solution are built in the order shown.

Figure 13. Build order
Build order

Project items build order

Within a DB2 database project, you can specify the build order for project script items. By default, all script files are built in the order they appear in the project.

You can choose a different build order using the Item Build Order dialog. This powerful feature lets you resolve cross-script dependencies in which one script file, ScriptX, may reference objects created in another script file, ScriptY, indicating that ScriptY must be compiled first.

Figure 14. Specifying the file build order
Specifying the file build order

Conclusion

The DB2 database project feature of the IBM DB2 Development Add-In for Visual Studio .NET is a set of tightly integrated set of tools that extends the Visual Studio .NET IDE to allow for rapid server-side development of DB2 objects.

Some of the advantages of using a DB2 database project over a Visual Studio .NET generic database project include:

  • Support for DB2 managed provider data connections from the IBM Explorer.
  • Full-featured scripting wizards for generating DB2-specific DDL and DML scripts.
  • Predefined SQL code fragment insertion in the editor.
  • Advanced scripting options support for error handling, display, and transaction management.
  • Specialized output pane for tracking detailed script execution results.
  • Support for multiple configuration options allowing for possibly different data connection and script build options.
  • Define the build order of script items within a project.
  • Content and dynamic help support.

Although the IBM DB2 Development Add-In provides you with many great features, we have barely begun to scratch the surface of our integration plans!


Notices

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing
IBM Corporation
North Castle Drive Armonk, NY 10504-1785
U.S.A.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=14358
ArticleTitle=DB2 Database Project for Visual Studio .Net
publish-date=04242003