Protocols and interfaces come in many forms. Now that we have
established that you are using SQL Server then you have many options which
your developers may be using with SQL2000.
They may be using the historical DBLib interface bound within the
application. For this you would select SQL Server as the protocol type
with the virtual user. The developers may have opted to make use of ODBC
for the connection to the database, choose the ODBC client type for
recording. Perhaps they even used OleDB for connections, with this you
have the option of DCOM or (what I prefer) pull the transaction logs for a
particular user conversation and recreate the conversation in an ODBC
client such as MSQUERY (ships as an applet for excel connectivity in
Microsoft office).
Lastly you can take a look at the advanced options within the vugen manual
for the creation of virtual users using Visual Studio. You can create
your virtual user directly from your application source files resulting in
a DLL based virtual user with a C/C++ or VB source.
TCP is the carrier protocol here, there is an application layer protocol
in play. For SQL Server it is most likely TDS, the tabular DataStream
Protocol, which is core to SQL Server. When you "hook" the application to
record for dblib, it records at the TDS layer. When you hook for ODBC
then it records at the API layer above the ODBC Driver Manager. For DCOM
it hooks to the COM interface of the operating system so you have to
filter out the universe except what you are interested in to build an
effective script (which is tedious unless you the developer of the
application sitting right next to you for extended periods of time).
'Pulley