Installing and Configuring Dynameasure

The first phase of the Dynameasure installation process is tomanually create two SQL Server databases: a test database to house the data touse during testing, and a control database to record the test results. To ensureyour tests are as clean as possible, place each database on a different SQLServer system. For the feature and operational tests I performed in thisanalysis, I used one SQL Server system. The manual that Bluecurve providesthoroughly documents the steps to create the two Dynameasure databases, butfamiliarity with SQL Server administration and maintenance procedures willgreatly ease this task.

While you're configuring SQL Server for Dynameasure, set up anadministrative user for the databases­a user with authority to maintainthem. In my testing, I simply used the Administrator user. In live testing, youwill want to create an additional user because you will need to enter the nameand password for this administrative user on the test manager and all the clientsystems. To my horror, I learned in version 1.0 that this user and passwordinformation is stored in the Registry in an unencrypted format, so choosewisely.

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

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

Note that you can install just the test manager programs on the test managersystem. This approach may be practical if you do not intend to run any motors onyour test manager system. The installation process I performed is theinstallation process Bluecurve recommends. Let me put this note another way­Ican't figure out why Bluecurve wants you to install all three program sets onthe 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 aDynameasure-specific password that you must get if you want full access to thetest manager programs. You also see a prompt for the name of the SQL server, thenames you assigned to the control and test databases, and username and passwordvalues to access those databases. For each database, you set up the sameusername and password values twice: once as an Administrator user and once as aregular user. The documentation tells you to use the same username and passwordvalues in both cases, so why you need to define the same user twice per databaseis another Dynameasure mystery.

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

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

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

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

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

%systemroot%system32;%systemroot%;;c:mssqlbinn

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

The correct format for the path variable is:

%systemroot%system32;%systemroot%;c:mssqlbinn;

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

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

I did have one after-the-fact complication with client softwareconfiguration: When I ran the client operator and motor software under alogged-on user account that was different from the user account I had for ODBCaccess, I was unable to get any test results. For example, I had configured myDynameasure connection to use the Administrator user for the databaseconnections, but I was logged under my usual account, enck. When I ranDynameasure 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 softwareso it ran under the Administrator logon, and it worked. Although I'm sure aperfectly valid security consideration is behind this problem, the manifestationof the problem is less than ideal­the product needs to detect such problemsbefore you run a test, not report them as corrupt data after the fact.