The first phase of the Dynameasure installation process is to manually create two SQL Server databases: a test database to house the data to use during testing, and a control database to record the test results. To ensure your tests are as clean as possible, place each database on a different SQL Server system. For the feature and operational tests I performed in this analysis, I used one SQL Server system. The manual that Bluecurve provides thoroughly documents the steps to create the two Dynameasure databases, but familiarity with SQL Server administration and maintenance procedures will greatly ease this task.

While you're configuring SQL Server for Dynameasure, set up an administrative user for the databases­a user with authority to maintain them. In my testing, I simply used the Administrator user. In live testing, you will want to create an additional user because you will need to enter the name and password for this administrative user on the test manager and all the client systems. To my horror, I learned in version 1.0 that this user and password information is stored in the Registry in an unencrypted format, so choose wisely.

The second phase is to install the test manager software. This software will be the central point of control for all tests, so you probably want to choose a system and a location that is convenient for the test administrator. Because Dynameasure relies on Open Database Connectivity (ODBC) connections to communicate with the SQL Server, ODBC drivers must be on the test manager system. If you have not previously installed ODBC on these systems, install the ODBC drivers from the Dynameasure CD before you install the main Dynameasure software. The Dynameasure manual describes this process well.

You invoke installation of the test manager software from a simple menu that the Setup program on the Dynameasure CD generates, as Screen A shows. To install the test manager software, click Complete Client and Server. In response, the Dynameasure installation program installs the following three program sets:

  • the test manager programs, including the Dispatcher, which lets you define and initiate tests; the Analyzer, which lets you evaluate test results; and the Builder, which sets up the control database on the SQL server (again, this is the database where test results are stored)
  • the client programs, including an Operator program, which communicates with the Dispatcher on the test manager system (via the SQL Server control database) and the Motor program, and is responsible for starting and stopping motors on the client system
  • the Workset Loader program, which is responsible for loading data into the SQL Server test database (during a normal installation you will not run this program on the test manager; instead, you will install and run it on the SQL server sponsoring the test database)

Note that you can install just the test manager programs on the test manager system. This approach may be practical if you do not intend to run any motors on your test manager system. The installation process I performed is the installation process Bluecurve recommends. Let me put this note another way­I can't figure out why Bluecurve wants you to install all three program sets on the test manager system, especially when you don't end up running the third set (the Workset Loader) on that system at all.

During installation of the test manager software, you must define a Dynameasure-specific password that you must get if you want full access to the test manager programs. You also see a prompt for the name of the SQL server, the names you assigned to the control and test databases, and username and password values to access those databases. For each database, you set up the same username and password values twice: once as an Administrator user and once as a regular user. The documentation tells you to use the same username and password values in both cases, so why you need to define the same user twice per database is another Dynameasure mystery.

I can, however, tell you to be sure to enter the username and password values correctly for the control database. When I was installing the software on my test manager system, I made a mistake entering the password pertaining to the control database. Because password entries are in a hidden field, I did not know I had made a mistake. Later in the installation process (when I attempted to build the control database), the manager failed on the database access because of the incorrectly typed password. But at that point, the test manager program set was completely hosed (in the technical sense), and I could not even get to the configuration menu to re-enter the information. I had to go into the Registry to reset the password field­and that (by the way) is when I learned that passwords are not stored in an encrypted format. Learn by my mistake: Enter all configuration information carefully.

After you install and configure the test manager software, the control database builder starts automatically. If you correctly enter all the database and access information, the Builder program connects to the SQL Server and generates the database structure for the test result data. This process can take a few minutes. On completion of the build, you have successfully installed the test manager system and can now proceed to the next phase, loading the test database into SQL Server.

But Wait, There's More...
The purpose of the third installation phase is to load test data into the test database on the SQL Server so the motors have some information to read and write. Bluecurve provides several test files so you can create a test database ranging from a few megabytes to more than a gigabyte in size. During the initial installation, Bluecurve recommends that you begin with the smallest test database.

To initiate this installation phase, you insert the Dynameasure Setup CD in your SQL Server, install the Workset Loader program, and then run the Workset Loader to select and load one of the test databases Bluecurve provides.

Unfortunately, this phase did not work in my test environment because of an error in the path variable in the NT environment properties. After I installed SQL Server 6.5 and the Dynameasure Workset Loader, the path statement read:

%systemroot%\system32;%systemroot%;;c:\mssql\binn

Note the two semicolons that appear before c:\mssql\ binn. They are wrong: One semicolon belongs before and one after c:\mssql\binn. This mistake prevented the Dynameasure Workset Loader on my SQL Server system from finding the SQL Server ISQL utility, so I could not load the test database.

The correct format for the path variable is:

%systemroot%\system32;%systemroot%;c:\mssql\binn;

You can correct this variable via the System applet in the Control Panel to let the Workset Loader run successfully. I also found I had to reboot my SQL Server system to put the change into effect. Then the Workset Loader ran without further complications.

The final phase of the installation is to install the client software. Each client system needs an ODBC driver, an operator, and a motor. As in the case of the test manager system, you can install ODBC drivers from the Dynameasure CD if they are not already installed. You then install the client software (the operator and the motor) through the Dynameasure Setup program. During installation, you receive a prompt to supply the name of the SQL Server system, the test database, the control database, and username and password information to access those databases.

I did have one after-the-fact complication with client software configuration: When I ran the client operator and motor software under a logged-on user account that was different from the user account I had for ODBC access, I was unable to get any test results. For example, I had configured my Dynameasure connection to use the Administrator user for the database connections, but I was logged under my usual account, enck. When I ran Dynameasure tests, they seemed to work, but when I tried to access the results, I got the message that my test data was corrupt. I then reinstalled the software so it ran under the Administrator logon, and it worked. Although I'm sure a perfectly valid security consideration is behind this problem, the manifestation of the problem is less than ideal­the product needs to detect such problems before you run a test, not report them as corrupt data after the fact.

Dynameasure 1.0
Bluecurve * 510-267-1500
Web: www.bluecurve.com
Price: $29,995 for a foundation license (50 motors); >$2495 for additional 25 motors