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 databasesa 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 wayI
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.