Data Integrity - FAQ

Yes. Our Tosca MCP Server offers a comprehensive toolset to help you test the validity of your table datasets and interpret the test results.

After you set up the Tosca MCP Server, you can ask your AI agent any further questions you have about Data Integrity.

Out of the box, Data Integrity supports all databases that support ODBC or JDBC drivers.

Tricentis recommends that you use the latest ODBC driver that is compatible with the OS and database. Data Integrity supports both 64-bit and 32-bit ODBC drivers.

Note that Data Integrity only uses ODBC drivers to access the data source. The ODBC driver capability decides what Data Integrity can support. For example, Oracle ODBC drivers don't support multiple SQL statements in a single script.

Data Integrity licenses are consumed if you have enabled the Data Integrity AddIn and start Tosca Commander.

Whenever you execute a Data Integrity Module, the system performs a license check and confirms that the license is still valid.

Whenever you run tests that contain Data Integrity Modules without starting the GUI, that is, Tosca Commander.

For example, if you use TC-Shell, TC API, or Tosca Distributed Execution instead.

You only need Data Integrity Parallel Execution licenses if you want to run Data Integrity tests in parallel, that is, at the same time.

For further information on licenses, contact your Tricentis sales person.

The Row by Row Comparison algorithm applies the following principles:

• The algorithm uses a set of columns as a unique identifier to compare rows. This identifier is the Row Key.

• You need to specify a Row Key to run Row by Row Comparison test. It can be one or more columns.

• The algorithm uses Row Key in the source dataset to find the corresponding row in the target dataset. Then it compares all remaining columns with each other.

To set up effective Row by Row Comparison tests, note the following:

• The Row Key should uniquely identify each row. If the Row Key isn't an unique identifier, the algorithm may match the wrong rows as it processes the source and target rows sequentially and doesn't look for additional context.

• Sort the source and target rows in the same way before you run a comparison, as it reduces test execution time and memory usage.

• The Row by Row Comparison ignores the rows where the Row Key has null values.

  To make sure that Tosca compares all the rows in your tables, run a Field Test for null values in your source and target Row Key columns. If the Field Tests find null values, you can use the Replace cell setting in the Row by Row Comparison to change the null value of those cells. Alternatively, set up your own SQL query that changes those values and add it to the SQL Statement Test Step.

If a Row Key is a duplicate and not unique, the algorithm performs automatic matching based on the remaining columns.

If automatic matching doesn't provide an exact match, the algorithm provides the most likely match based on the number of cells that match.

By default, Data Integrity tries to determine the total number of rows from the source before it starts the comparison. This allows Data Integrity to display the remaining time.

If this process takes too long or you don't need the time frame, you can skip the row count.

The row count only provides more detailed information on the execution progress, it has no influence on the comparison itself.

Data Integrity offers multiple execution options. Ultimately, your setup determines which execution is suitable and most advantageous for you.

Scroll through the list below for an overview of advantages () and disadvantages () of specific execution options:

Run local Tosca TBox execution and access data through ODBC or JDBC
Execution runs closer to data All execution happens on one machine Fast data access for local data	Might be slow when you compare large remote data sets Only runs on Windows and not on Linux

Run local Tosca TBox execution through Tosca Distributed Execution (DEX), Data Integrity execution runs on DEX Agent
Orchestration is available	Can't run on Linux

To run your tests with Row by Row Comparison, you have to specify the class name of your JDBC driver in your TestCase. If you don't know the class name, you can find it in the Java Archive (JAR) file of your JDBC driver.

See the examples below to learn how to find a JDBC driver class name in two different ways.

Example 1: Find the class name in the manifest file

This example uses the manifest file to find the driver class name. The manifest is a text file that contains essential information about a JAR file's content. You have to perform the following steps:

1. To extract the content of your JAR file, rename it by adding the extension .zip.

   For example, rename your file from ojdbc7.jar to ojdbc7.jar.zip.

2. Double-click the ZIP file and extract the content.

3. Search the extracted content for a file called MANIFEST.MF.

4. Open the manifest file and look for the Main-Class which should specify the class name.

   In this example, the file states Main-Class: oracle.jdbc.OracleDriver.

The driver class name is oracle.jdbc.OracleDriver. You can now use this information in the TestStep.

If the class name isn't specified in the Main-Class, try out the steps in the next example.

Example 2: Find the class name in the META-INF/services folder

This example uses the META-INF/services folder to find the driver class name. This folder contains information by the service provider. You have to perform the following steps:

1. To extract the content of your JAR file, rename it by adding the extension .zip.

   In this example, you rename your file from mssql-jdbc-8.2.2.jre11.jar to mssql-jdbc-8.2.2.jre11.jar.zip.

2. Double-click the ZIP file and extract the content.

3. Search the extracted content for a folder called META-INF\services.

4. In this folder, open the file java.sql.Driver which should contain the class name.

   In this example, the file states: com.microsoft.sqlserver.jdbc.SQLServerDriver.

The driver class name is com.microsoft.sqlserver.jdbc.SQLServerDriver. You can now use this information in the TestStep.