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.