Database Protocols - Troubleshooting and Limitations

This section describes troubleshooting and limitations for database protocols.

Tip: For general VuGen troubleshooting and limitations, see Troubleshooting and limitations for VuGen.

Troubleshooting all database protocols

Evaluating Error Codes

When a Vuser executes an LRD function, the function generates a return code. A return code of 0 indicates that the function succeeded. For example, a return code of 0 indicates that another row is available from the result set. If an error occurs, the return code indicates the type of error. For example, a return code of 2014 indicates that an error occurred in the initialization.

There are four types of return codes, each represented by a numerical range:

Type of Return Code
Range
Informational
0 to 999
Warning
1000 to 1999
Error
2000 to 2999
Internal Error
5000 to 5999

For more detailed information on the return codes, see the Function Reference.

You can evaluate the return code of an LRD function to determine if the function succeeded. The following script segment evaluates the return code of an lrd_fetch function:

static int rc;
rc=lrd_fetch(Csr15, -13, 0, 0, PrintRow4, 0);
if (rc==0)
    lr_output_message("The function succeeded");
else
    lr_output_message("The function returned an error code:%d",rc);

Back to top

Two-tier Database Scripting Tips

The following section offers solutions for two-tier database scripts.

Back to top

Troubleshooting Oracle 2-Tier Vusers

This section contains a list of common problems that you may encounter while working with Oracle Vusers, and suggested solutions.

ORA-20001 and ORA-06512

Errors ORA-20001 and ORA-06512 appear during replay when the lrd_stmt contains the pl/sql block: fnd_signon.audit_responsibility(...)

This statement fails during replay because the sign-on number is unique for each new connection.

Solution

In order to solve this problem you need to use the new correlation tool for the sign-on number. This is second assigned value in the statement.

After you scan for possible values to correlate, highlight the value of the second lrd_assign_bind() for the failed statement. Note that the values in the "correlated query" window may not appear in the same order as the actual recorded statements.

The grid containing the substitution value should appear after the lrd_stmt which contains the pl/sql block: fnd_signon.audit_user(...).

Note: Since the sign-on number is unique for every connection, you need to use correlation for each new connection that you record.

Example of Solution

The following statement failed in replay because the second value, "1498224" is the unique sign-on number for every new connection.

lrd_stmt(Csr6, "begin fnd_signon.audit_responsibility(:s,:l,:f,:a,:r,:t,:p)"

"; end;", -1, 1, 1, 0);

lrd_assign_bind(Csr6, "s", "D", =;s_D216, 0, 0, 0);

lrd_assign_bind(Csr6, "l", "1498224", =;l_D217, 0, 0, 0);

lrd_assign_bind(Csr6, "f", "1", =;f_D218, 0, 0, 0);

lrd_assign_bind(Csr6, "a", "810", =;a_D219, 0, 0, 0);

lrd_assign_bind(Csr6, "r", "20675", =;r_D220, 0, 0, 0);

lrd_assign_bind(Csr6, "t", "Windows PC", =;t_D221, 0, 0, 0);

lrd_assign_bind(Csr6, "p", "", =;p_D222, 0, 0, 0);

lrd_exec(Csr6, 1, 0, 0, 0, 0);

The sign-on number can be found in the lrd_stmt with "fnd_signon.audit_user". The value of the first placeholder "a" should be saved. The input of "a" is always "0" but the output is the requested value.

Modified code:

lrd_stmt(Csr4, "begin fnd_signon.audit_user(:a,:l,:u,:t,:n,:p,:s); end;", -1, 1, 1, 0);

lrd_assign_bind(Csr4, "a", "0", =;a_D46, 0, 0, 0);

lrd_assign_bind(Csr4, "l", "D", =;l_D47, 0, 0, 0);

lrd_assign_bind(Csr4, "u", "1001", =;u_D48, 0, 0, 0);

lrd_assign_bind(Csr4, "t", "Windows PC", =;t_D49, 0, 0, 0);

lrd_assign_bind(Csr4, "n", "OraUser", =;n_D50, 0, 0, 0);

lrd_assign_bind(Csr4, "p", "", =;p_D51, 0, 0, 0);

lrd_assign_bind(Csr4, "s", "14157", =;s_D52, 0, 0, 0);

lrd_exec(Csr4, 1, 0, 0, 0, 0);

lrd_save_value(=;a_D46, 0, 0, " saved_a_D46");

Grid0(17);

lrd_stmt(Csr6, "begin fnd_signon.audit_responsibility(:s,:l,:f,:a,:r,:t,:p)"

"; end;", -1, 1, 1, 0);

lrd_assign_bind(Csr6, "s", "D", =;s_D216, 0, 0, 0);

lrd_assign_bind(Csr6, "l", " <saved_a_D46>", =;l_D217, 0, 0, 0);

lrd_assign_bind(Csr6, "f", "1", =;f_D218, 0, 0, 0);

lrd_assign_bind(Csr6, "a", "810", =;a_D219, 0, 0, 0);

lrd_assign_bind(Csr6, "r", "20675", =;r_D220, 0, 0, 0);

lrd_assign_bind(Csr6, "t", "Windows PC", =;t_D221, 0, 0, 0);

lrd_assign_bind(Csr6, "p", "", =;p_D222, 0, 0, 0);

lrd_exec(Csr6, 1, 0, 0, 0, 0);

Working with large numbers

Large numbers (NUMBER data type) sometimes appear in different format in the GRID and in the ASCII file. This difference makes it more difficult to identify numbers while searching for values to save for correlation.

For example, you could have a value appear as 1000003 in the grid, but as 1e+0006 in the Recording Log (ASCII file).

Workaround

If you have an error during replay and the correlation tool cannot locate the value in previous results, look for this value in the other format in grid.

ORA-00960

This error may occur with non-unique column names. For example:

lrd_stmt(Csr9, "SELECT UOM_CODE, UOM_CODE, DESCRIPTION FROM "

"MTL_UNITS_OF_MEASURE "

"WHERE NVL(DISABLE_DATE, SYSDATE + 1) > "

"SYSDATE ORDER BY UOM_CODE", -1, 1, 1, 0);

In this case you receive the following error:

"lrdo.c/fjParse: "oparse" ERROR return-code=960, oerhms=ORA-00960: ambiguous column naming in select list".

Workaround

Change the statement by adding an alias to at least one of the non-unique columns, thus mapping it to a new unique name. For example:

lrd_stmt(Csr9,"SELECT UOM_CODE,UOM_CODE second, DESCRIPTION FROM"

"MTL_UNITS_OF_MEASURE "

"WHERE NVL(DISABLE_DATE, SYSDATE + 1) > "

"SYSDATE ORDER BY UOM_CODE", -1, 1, 1, 0);

Alternate Workaround: remove ORDER BY from the lrd statement.

ORA-2002

Error 2002 appears when you try to use an unopened cursor. It occurs when you replay a user more than one iteration and you recorded into more than one section of the script.

Specifically, if a cursor is opened in the vuser_init section and closed in the Actions section, then you will encounter this error on the second iteration if you try to use the cursor. This is because it was closed but not re-opened.

For example: You have lrd_open_cursor in the vuser_init section and lrd_close_cursor in the Actions section. If you replay this user more than one iteration, you are going to get an error in the second iteration because you try using an unopened cursor (it was closed in the first iteration, but not re-opened in the second).

Workaround

The easiest way to solve this is to move the lrd_close_cursor or/and lrd_close_connection of the problem cursor to the vuser_end section.

Database Protocols (lrd)

Replay of recorded asynchronous operations is not supported.

Wrong Client Version

You may receive an error message when running the wrong Oracle client version:

"Error: lrdo_open_connection: "olog" LDA/CDA return-code_019: unable to allocate memory in the user side"

Workaround

You need to modify the library information in the lrd.ini file, located in the product's bin folder. This file contains the settings that indicate which version of database support is loaded during recording or replay. The file contains a section for each type of host.

For example, the following section of the lrd.ini file is for Oracle on Windows NT:

[ORACLE_WINNT]

805=lrdo32.dll+ora805.dll
816=lrdo32.dll+oci.dll
815=lrdo32.dll+oraclient8.dll
804=lrdo32.dll+ora804.dll
803=lrdo32.dll+ora803.dll
73=lrdo32.dll+ora73.dll
72=lrdo32.dll+ora72.dll
71=lrdo32.dll+orant71.dll

These settings indicate that Vusers should use the ora805.dll library if the client uses Oracle 8.0.5, oci.dll for Oracle 8.1.6, and so on.

Back to top