Page History

This topic explains how to configure and apply the DB tool in SOAtest and Virtualize. This tool allows you to query databases 

...

databases for validating SQL statements with SOAtest

...

.

Sections include:

...

If your test suite has a Database Account shared property, you can connect  Use Local Settings,Use Shared Property, or Use Both. These options enable you to use only settings within the corresponding DB tool, settings from a shared global database account (global database settings that you added to the test suite as a Global Property), or both. For more information on how to define shared properties and export them to a file, see 

...

Global Database Account Properties

...

.

...

For more information on configuring database connection settings, see condition 

...

Database Configuration Parameters in SOAtest andAdding Global Test Suite Properties.

SQL Query Tab

• SQL Query: Allows you to specify either a Fixed or Parameterized SQL statement.
  • If Fixed is selected, you can do finergrain parameterization by entering the special string ${column} into the text box and selecting a data source from the Data Source drop-down menu. During runtime, the tool will look up the column in the specified data source. Any string value can be parameterized.
    For example, if a data source is created and has three rows that contain CA, NY, and WA, you can enter the following into the Fixed text box:
    

    SELECT *
FROM People
WHERE state = ’${States}’

    When ran, the DB tool will create the following queries:

    SELECT *
FROM People
WHERE state = "CA"

    SELECT *
FROM People
WHERE state = "NY"

    SELECT *
FROM People
WHERE state = "WA"

    To access values from a Writable Data Source, use

    ${<Data Source Name>: <Column Name>}

    Note that there needs to be a space between the colon and  <Column Name>

    To access values from an XML Data Bank, use 

    ${<Data Source Column Name mapped to Selected Element>}

• Separate statements by semicolon (;): If this option is enabled, the tool will divide the contents of the SQL query editor by semicolon. For more details, see Statement Separation Behavior.
• Separate statements by Magic Token (typically used for stored procedures):  If this option is enabled, the tool will divide the contents of the SQL query editor by the provided magic token string. A magic token is a string that starts at the beginning of a line and contains only the magic token (with optional white space after the token). For more details, see Statement Separation Behavior.
• JDBC OUT parameter types for stored procedures: Allows you to invoke stored procedures and functions that take OUT parameters or return a value.
  • You can leave this field empty if you are executing a regular SQL query or a stored procedures that does not have any OUT parameters. See JDBC OUT Parameter Types for Stored Procedures below for details.
  • Note that for each DB tool, the same JDBC OUT parameters are sent to each callable statement. To use different out parameters, create a separate DB tool.
    
    

...

The types you list in that field can be separated with spaces or commas, and the type names correspond to the field names in the class java.sql.Types (http://docs.oracle.com/javase/8/docs/api/java/sql/Types.html) or oracle.jdbc.OracleTypes class fields (http://download.oracle.com/docs/cd/A97329_03/web.902/q20224/oracle/jdbc/OracleTypes.html).

...

 will SOAtest will look for the type you provide in java.sql.Types first. If it is not found there, it will look for it in oracle.jdbc.OracleTypes. The type name you provide is passed to the JDBC CallableStatement.registerOutParameter().

...

Oracle databases support various proprietary data types. If your database utilizes these data types, you must add the appropriate jar(s) to 

...

 classpath to the JDBC classpath in the Preferences panel (under Parasoft> JDBC Drivers).

...