GigaMegaBlog

As I’ve written in my past articles about Infragistics NetAdvantage for .Net, we’ve been stuck on an older version for some time.  I was worried that an upgrade would introduce some new bugs and other code-breaking changes.  NetAdvantage has a rich feature set that Infragistics aggressively adds to four times a year, but as a result the product has a relatively high number of bugs for a development tool. Over the months we’ve developed workarounds for the bugs and other eccentricities in the older version of NetAdvantage, and with the team focused on adding new functionality to our product I hated to throw a new variable into the mix.

We finally took the plunge a few weeks ago, upgrading from 2007 Volume 1 to the latest and greatest, 2008 Volume 2. I was relieved to find that it was an almost pain-free transition.

The only bump that we hit wasn’t even a bug in the current version: it might have been a bug in 2007 Vol 1 that they fixed, or just an undocumented syntax change. The problem occurred in code which identified an UltraGrid band by key rather than index number:

// by key:
UltraGridColumn colCode = grid.DisplayLayout.Bands["clsOurObject"].Columns[“code”];

// by index:
UltraGridColumn colName = grid.DisplayLayout.Bands[0].Columns[“name”];

Our coding standard was to identify bands by key rather than index number in multi-band grids, in case the grid was reorganized and a band was added or removed.

The UltraGrid band key is read-only, being automatically set by the Infragistics code.  When we first started using NetAdvantage in 2006, I noticed that the key for the first-level band was set to the name of the underlying class, but the keys for the child bands were set to the name of the list variable which contained the band’s rows.  Strange, but not something that ruined my day.  Life went on.

However, after the upgrade to 2008 Volume 2, this eccentricity became a problem.  The key names were now all based on the list variable name.  After fruitlessly poking around the UltraGrid’s properties and methods for an option that would change things back to the way they were, I gave up and went with the low tech approach of changing all the band key references in our code:

//UltraGridColumn colCode = grid.DisplayLayout.Bands["clsOurObject"].Columns[“code”];
// new key name:
UltraGridColumn colCode = grid.DisplayLayout.Bands["lstOurStuff"].Columns[“code”];

We posted the problem to Infragistics’ support forum, and their support team was surprised that our original code had ever worked when using the class name as the key.  So, the problem remains unexplained: strange, but still not something that ruined my day.

I haven’t taken advantage of the new functionality yet, but one clear and unexpected advantage from the upgrade is a marked performance improvement in large grids. We have a window which loads massive amounts of data into a two-level grid: sometimes over a million rows.  A grid of 200,000 rows which used to take about 30 seconds to load on my development PC (measured from the point that the underlying list was populated until the grid was up and responsive to user input) now takes just 6 seconds.  Navigating through this type of large grid and applying sorts and filters is also noticeably faster – sorting the 200,000 row grid takes less than a second, filtering takes about 3.  The Release Notes mention some tweaking that Infragistics did to the grid back in Version 2007 Volume 3, but I didn’t expect an improvement on this scale.

A major update with just 1 bug and a huge performance boost: that’s what I call a upgrade!

Having made the leap over to IBM’s new "DB2 Client" ADO.Net driver for the U2 UniVerse database, we recently spent some time figuring out how to get it onto users’ PCs.  This turned out to be harder than I expected, and harder than it should be.

The new Data Client’s installer was actually a big selling point for us.  The previous database driver, UniOLEDB, used a proprietary install program that didn’t support automated, silent installs.  This means that someone from the user’s IT department had to visit each user’s desktop and 1) launch the install program, 2) click Next a bunch of times, 3) phone us and complain about how annoying this is.  Every install program that we’ve created or incorporated into our product for the last 10 years has supported silent installs, except this one.  

I was so giddy at the prospect of moving on to a proper installer that I assured our clients that we would now fully support silent installs without (ahem) actually trying to do one.  My optimism was based on the fact that 1) the new database client uses the same installer as IBM’s flagship database, DB2, 2) this installer was created using one of the industry standard tools, InstallShield, which has supported silent installs for ages, and 3) the DB2 Information Center’s extensive documentation includes a section entitled "Silent Installation".  It sure looks easy when you read about it.

Unfortunately, it doesn’t quite work the way it’s described, and finding the specifics required quite a lot of Googling as well as some trial and error. 

Here’s what doesn’t work:

1) Installing without a response file.  This will launch the installer, but it will quickly abort, and the error message written to the log is enigmatic:

Action ended 20:06:46: DB2SetDB2INSTANCECA.2BC48F01_561E_4906_8321_946A9F5A90AA. Return value 3.
Action ended 20:06:46: INSTALL. Return value 3.
MSI (s) (E4:68) [20:06:46:607]: Product: IBM Data Server Runtime Client – DB2COPY1 — Configuration failed.

Presumably, the response file is mandatory.

2) The standard InstallShield command line switch for generating a response file in the Windows folder (-r).  I never thought that the Windows folder was a great place to put it — apparently IBM agrees.

3) The Response File Generator utility (db2rspgn).  Although this utility does, indeed, generate a response file, we had absolutely no luck when trying to use this response file to do an install.  Googling the problem suggested that many others had the same result, but I still have no idea what the solution is, if any.

4) Manually editing one of the sample response files, as suggested by the Information Center, might have worked if we actually had a sample response file.  The sample response files are apparently located on the "Information Integration Product DVD", but I’ve never seen such a beast.

Here’s what does work:

1) Run the installer normally (with no command line switches), then look in your %TEMP% folder.  Sure, enough, there’s a .rsp file left behind in there. 

2) This response file works just fine with the standard InstallShield parameters for a silent install.  For the current version of the DB2 runtime client, this is :

v9.5fp2_nt32_rtcl_en.exe /v"/qn RSP_FILE_PATH=<path of the .rsp file>.

The contents of the elusive response file are somewhat of a letdown.  Unless you need to install 2 different versions of the database drivers, you’re unlikely to ever want to change a thing.   Should you not have an Information Integration Product DVD at hand, feel free to use our response file as a sample:

PROD=RUNTIME_CLIENT
INSTALL_TYPE=TYPICAL
DB2_COPY_NAME=DB2COPY1
DEFAULT_COPY=YES
DEFAULT_CLIENT_INTERFACE_COPY=YES
DEFAULT_INSTANCE=DB2
INSTANCE=DB2
DB2.NAME=DB2
LIC_AGREEMENT=ACCEPT