DB2 Universal Database and the .NET Developer - The IBM Explorer
The great things about the IBM Explorer
So, now that you are comfortable with the fact that you can build your .NET applications with DB2 UDB in the same manner that you build your SQL Server applications, I want to share with you some of those productivity enhancements I alluded to earlier.
Connecting to development databases
One of the really cool features in the IBM Explorer is the ability to discover databases and dynamically add them to the IBM Explorer tree view without leaving the IDE. Traditionally, a database administrator (DBA) would likely have to set a database connection on an application developer's workstation, or use some of the existing tooling to specify the server name of the target database, and more.
DB2 products come with the Add DB2 Data Connection wizard, which allows you to discover databases on your network. Of course, your DBAs have to ensure that you have been granted access credentials to those databases, and they can configure databases to respond to or ignore DB2 UDB discovery requests. By clicking the Refresh button in the wizard, the local DB2 UDB client code sends out a broadcast message asking eligible DB2 UDB servers to respond with configuration information.
From here, the application developer simply needs to select which server and database to connect to, and let the development begin.
You can also use the Options tab to customize z/OS build options on a per connection and per project basis.
Many developers elect to set up multiple connections to the same database with different connection options and credentials, as shown below:
You can see in the preceding figure that I have set up two different connections to the BANKDB database: namely, BANKDBDEVELOPERS and BANKDBTESTERS.
Filtering database connections
One thing IBM heard from application developers is that when they work with databases that have a large number of objects, the amount of time it takes to populate the object tree can become unacceptable. For example, consider an SAP application that can contain up to 30,000 database objects - this task just screams coffee time.
The IBM Explorer includes a filter with granularity at the database object layer. Using IBM Explorer, you can filter the following objects: tables, views, stored procedures, and functions. This gives applications developers a lot of granularity beyond a filter applied at the database level (which you can do as well).
The figure below shows the Table folder expanded on the default DB2 UDB SAMPLE database:
Using the filter option, you can restrict the tables returned in this folder by schema, name, or a combination of these. In the example below, I set a filter such that the only objects in the Tables branch have or contain the key name *STAFF*:
When this filter is applied, the Tables branch in the database object tree looks like this:
This filter can make working across varying teams and with large databases more productive for developers programming to DB2 UDB databases.
Working without a database connection
When using the Server Explorer, no matter what database you are programming to, you need to have a connection to the database to browse the objects within them and build your applications.
You can see in the following figure that despite the fact that the database manager isn't started (see the highlighted text in the figure), I was still able to drag-and-drop a table object onto my WinForm. More on this in a bit.
The DB2 UDB add-in creates a cache of the schema (stored in XML) that resides underneath the IBM Explorer. This not only allows application developers to work with the database schema in offline mode, but also assists in syntax checking without having to build your solution.
Quite simply, you do not have to be connected to the database to build your application. If you were building an application from the Server Explorer and the database instance was not started, depending on the vendor's database, you would either be blocked from using the entire IDE until an error was returned, or you would not be able to expand the database object tree.
Page 2 of 3