A single table needs to be used multiple times as an input. However, when using the same table within the same tMap component, it becomes difficult to distinguish between each usage. This issue exists across all tMap-related components, such as tELTGreenplumMap.

Resolution

Use the same table as multiple inputs by adding it multiple times in the tMap component. Assign a different alias to each instance of the table so they can be clearly distinguished and used independently.

Environment

• Qlik Talend Studio

Why does Qlik Replicate perform a full table scan on an Oracle source table PK defined as REAL/FLOAT?

Resolution

Avoid using REAL/FLOAT data types for table PKs with LOBs in the tables. 

Cause

Using an Oracle source, if the table PK in the source Oracle is defined as REAL/FLOAT and the table has LOBs, each lookup will become a full table scan due to host variable binding data type.

Environment

• Qlik Replicate

A Qlik Replicate task fails with the error:

[TARGET_APPLY ]I: Failed executing truncate table statement: TRUNCATE TABLE "PAYOR_DW"."attrep_changesBF9CC327_0000069" [1020403] (oracle_endpoint_load.c:856) 00006000: 2025-09-27T18:41:59 [TARGET_APPLY ]I: ORA-03135: connection lost contact Process ID: 19637 Session ID: 1905 Serial number: 3972 [1022307] (oracle_endpoint_load.c:862) 00006000: 2025-09-27T18:41:59 [TARGET_APPLY ]I: Failed to truncate net changes table [1022307] (oracle_endpoint_bulk.c:1162) 00006000: 2025-09-27T18:41:59 [TARGET_APPLY ]I: Error executing command [1022307] (streamcomponent.c:1987) 00006000: 2025-09-27T18:41:59 [TASK_MANAGER ]I: Stream component failed at subtask 0, component st_0_PCA UAT DW Target [1022307] (subtask.c:1474) 

Resolution

The issue is that there is a database-level trigger to monitor drop/truncate and alter statements by name "TSDBA.AUDIT_DDL_TRG" which is currently invalid.

A possible fix is to validate this trigger and also add logic in this trigger to not consider attrep_changes% tables, as this is just a temp table for Qlik Replicate batch processing.

Environment

• Qlik Replicate

When creating a task, the following error message appears in the dataset information section (where the table column names are displayed).

Error:

converter xxxx not found
 

ConverterError 
 

Resolution

Set correct CCSID to Character set mapping in the task settings.

For Example:

set 1027,939 in CCSID to Character set mapping

Cause

Qlik Talend Data Integration depends on standard ICU modules to perform code-page conversion for IBM DB2 for z/OS and IBM DB2 for iSeries data. These conversion modules are provided by ICU itself.

However, certain converter modules may be missing in the environment. When this occurs, the affected CCSID must be mapped manually to a compatible superset to ensure proper character conversion.

Environment

Qlik Data Gateway  

Extracting data to Qlik Sense Enterprise on Windows from an SAP BW InfoProvider / ASDO with two values in a WHERE clause fails with an error similar to the following: 

Data load did not complete
Data has not been loaded. Please correct the error and try loading again.

Using only one field value in the WHERE clause, it works as expected.

Resolution

• Upgrade the Qlik SAP Connector to Qlik SAP Connector version 8.3.0
• Ensure you have also imported Qlik SAP Transport version 8.3.0

Related Content

• Qlik Cloud Direct Access Data Gateway: extracting data from SAP BW InfoProvider / ASDO with two values in a WHERE clause returns 0 lines

Internal Investigation ID(s)

• SUPPORT-5101

Environment

• Qlik Sense Enterprise on Windows
• SAP Connector v8.1.0

When using Google Cloud Storage as a target in Qlik Replicate, and the target File Format is set to Parquet, an error may occur if the incoming data contains invalid values.

This happens because the Parquet writer validates data during the CSV-to-Parquet conversion. A typical error looks like:

[TARGET_LOAD     ]E:  Failed to convert file from csv to parquet
Error:: failed to read csv temp file
Error:: std::exception [1024902]  (file_utils.c:899)

Environment

• Qlik Replicate all versions
• Google Cloud Storage all versions

Resolution

There are two possible solutions:

• Clean up or remove the incorrect records in the source databases
• Or add a transformation to correct or replace invalid dates before they reach the target.

Cause

In this case, the source is SAP Oracle, and a few rare rows contained invalid date values. Example: 2023-11-31.

By enabling the internal parameters keepCSVFiles and keepErrorFiles in the target endpoint (both set to TRUE), you can inspect the generated CSV files to identify which rows contain invalid data.

Internal Investigation ID(s)

00417320

Recent versions of Qlik connectors have an out-of-the-box value of 255 for their DefaultStringColumnLength setting. 

This means that, by default, any strings containing more than 255 characters is cut when imported from the database.

To import longer strings, specify a higher value for DefaultStringColumnLength.

This can be done in the connection definition and the Advanced Properties, as shown in the example below. 

The maximum value that can be set is 2,147,483,647.

Environment

• Qlik Connectors
• Built-in Connectors Qlik Sense Enterprise on Windows November 2024 and later

How does Qlik Replicate convert DB2 commit timestamps to Kafka message payload, and why are we seeing a lag of several hours?

1. When Qlik Replicate reads change events from the DB2 iSeries journal, each journal entry includes both:
   • Entry timestamp: when the individual operation was logged; from JOENTTST. Qlik Replicate does not use it.
   • Commit timestamp: when the transaction was committed; from JOCTIM. This is what Qlik Replicate uses as the payload timestamp field.
2. Then Qlik Replicate converts DB2 iSeries journal commit timestamps to UTC 
   • Qlik Replicate normalizes all internal event timestamps to UTC before serializing the payload, regardless of the source system’s local timezone.
   • This guarantees downstream consumers (Kafka / Schema Registry / Avro) have a single consistent time base.
3. Qlik Replicate then populates the data.timestamp field in the Kafka message payload.
   • The timestamp field in the Kafka message payload represents the commit timestamp of the transaction as recorded in the DB2i journal in UTC timezone. This does not use the Kafka broker's or source DB2 i system's local timezone.
   • An offset of several hours here is due to timezone normalization, not replication lag. 
4. Note that some operations (DDL, full-load, or deletes) may omit data.timestamp because no valid source commit time exists. This is also expected behavior.
   • DDL: Not tied to a commit
   • Full Load: No CDC commit time yet
   • Delete: DB2 journals don’t always include a valid commit timestamp for the before-image

Environment

• Qlik Replicate

Qlik Geocoding operates using two QlikGeoAnalytics operations: AddressPointLookup and PointToAddressLookup.

Two frequently asked questions are:

• Does Qlik Geocoding work with a custom GeoAnalytics Server, or does it require a connector type "Cloud"?
• Do you need an online connection for Qlik Geocoding?

The Qlik Geocoding add-on option requires an Internet connection. It is, by design, an online service. You will be using Qlik Cloud (https://ga.qlikcloud.com), rather than your local GeoAnalytics Enterprise Server.

See the online documentation for details: Configuring Qlik Geocoding. 

Environment

• Qlik Cloud
• Qlik GeoAnalytics

This article outlines how to handle DDL changes on a SQL Server table as part of the publication. 

Resolution

The steps in this article assume you use the task's default settings: full load and apply changes are enabled, full load is set to drop and recreate target tables, and DDL Handling Policy is set to apply alter statements to the target.

To achieve something simple, such as increasing the length of a column (without changing the data type), run an ALTER TABLE command on the source while the task is running, and it will be pushed to the target.

For example: alter table dbo.address alter column city varchar(70) 

To make more complicated changes to the table, such as: 

• Changing the Allow Nulls setting for a column
• Reordering columns in the table
• Changing the column data type
• Adding a new column
• Changing the filegroup of a table or its text/image data

Follow this procedure: 

1. Stop the task
2. Remove the table from the task
3. Remove the table from the publication.
   Some changes do not require this, and some do. Removing it from the publication will work in all cases. 
   1. Right-click the publication (starts with AR_) and select Properties
   2. Click to select the Articles tab
   3. Uncheck the box next to the table and click OK
   4. Copy all the data to a temp table
4. Recreate the table with the needed modifications
5. Copy the data back into the table
6. Add the table back to the task and resume. This will automatically add the table back to the publication and reload the table on the target. Reference: Saving changes is not permitted error message in SSMS

Environment

• Qlik Replicate

When connecting to Microsoft OneDrive using either Qlik Cloud Analytics or Qlik Sense Enterprise on Windows, shared files and folders are no longer visible.

Resolution

While the endpoint may intermittently work as expected, it is in a degraded state until November 2026. See drive: sharedWithMe (deprecated) | learn.microsoft.com. In most cases, the API endpoint is no longer accessible due to the publicly documented degraded state.

Qlik is actively reviewing the situation internally (SUPPORT-7182).

However, given that the MS API endpoint has been deprecated by Microsoft, a Qlik workaround or solution is not certain or guaranteed.

Suggested Workaround

Use a different type of shared storage, such as mapped network drives, Dropbox, or SharePoint, to name a few. 

Cause

Microsoft deprecated the /me/drive/sharedWithMe API endpoint.

Internal Investigation ID(s)

SUPPORT-7182

Environment

• Qlik Cloud
• Qlik Sense Enterprise on Windows

Extracting data from SAP BW InfoProvider / ASDO with two values in a WHERE clause returns 0 lines.

Example:

The following is a simple standard ADSO with two infoObjects (‘0BPARTNER’,  ‘/BIC/TPGW8001’,) and one field (‘PARTNUM’). All are CHAR data type. 

In the scripts we used [PARTNUM] = A, [PARTNUM] = B in the WHERE clause.

However 

• If you use only one field value in the WHERE clause, it works as expected:
  From GTDIPCTS2
Where ([PARTNUM] = A); 
• If you use two values infoObject [TPGW8001] instead of the field [PARTNUM] in the WHERE clause, it also works as expected:
  From GTDIPCTS2
Where ([TPGW8001] = “1000”,  [TPGW8001] = “1000”); 

Environment

• Qlik Cloud / Direct Data Gateway version 1.7.4
• SAP BW Connector

Resolution

Upgrade to Direct Data Gateway version 1.7.8.

Cause

Defect SUPPORT-5101

Related Content

• Qlik Sense Enterprise on Windows and SAP Connector v8.1.0: Data load error when extracting data from SAP BW InfoProvider and WHERE clause has 2 values 

Internal Investigation ID(s)

SUPPORT-5101

When using Google Cloud Pub/Sub as a target and configuring Data Message Publishing to Separate topic for each table, the Pub/Sub topic may be unexpectedly dropped if a DROP TABLE DDL is executed on the source. This occurs even if the Qlik Replicate task’s DDL Handling Policy When source table is dropped is set to Ignore DROP.

Environment

• Qlik Replicate versions before 2025.5 SP3

Resolution

This issue has been fixed in the following builds:

• 2025.5.0.454 (SP3)
• 2025.11 GA

To apply the fix, upgrade Qlik Replicate to one of the listed versions or any later release.

Cause

A product defect in versions earlier than 2025.5 SP3 causes the Pub/Sub topic to be dropped despite the DDL policy configuration.

Internal Investigation ID(s)

• 00401331

A Job design is presented below:

tSetKeystore: set the Kafka truststore file.

tKafkaConnection, tKafkaInput: connect with Kafka Cluster as a Consumer and transmits messages.

However, while running the Job, an error exception occurred under the tKafkaInput component.

org.apache.kafka.common.KafkaException: Failed to construct kafka consumer 

Resolution

Make sure to execute the tSetKeyStore component prior to the Kafka components to enable the Job to locate the certificates required for the Kafka connection. To achieve this, connect the tSetKeystore component to tkafkaConnection using an OnSubjobOK link, as demonstrated below:

For more detailed information on trigger connectors, specifically OnSubjobOK and OnComponentOK, please refer to this KB article: What is the difference between OnSubjobOK and OnComponentOK?.

Environment

• Talend Data Integration 7.3.1, 8.0.1

This article addresses the error encountered during extraction when using log-based incremental replication for MySQL integration:

[main] tap-hp-mysql.sync-strategies.binlog - Fatal Error Occurred - <ColumnName> - decimal SQL type for value type class clojure.core$val is not implemented.

Resolution

There are two recommended approaches:

Option 1: Enable Commit Order Preservation

Run the following command in your MySQL instance:

SET GLOBAL replica_preserve_commit_order = ON;

Then, reset the affected table(s) through the integration settings.

Option 2: Validate Replication Settings

Ensure that either:

• replica_preserve_commit_order (MySQL 8.0+), or
• slave_preserve_commit_order (older versions)

is enabled. These settings maintain commit order on multi-threaded replicas, preventing gaps and inconsistencies.

How to Check if Setting is Enabled

Run:

SHOW GLOBAL VARIABLES LIKE 'replica_preserve_commit_order';

Expected Output:

For older versions:

SHOW GLOBAL VARIABLES LIKE 'slave_preserve_commit_order';

For more information, reference MySQL Documentation

replication-features-transaction-inconsistencies | dev.mysql.com

Cause

When using log-based incremental replication, Stitch reads changes from MySQL’s binary log (binlog). This error occurs because the source database provides events out of order, which leads to mismatched data types during extraction. In this case, the extraction encounters a decimal SQL type where the value type is unexpected.

Why does this happen?

• Non-transactional DML statements that do not guarantee ordering.
• Misconfigured or inconsistent replication setup.
• Multi-threaded replication without commit order preservation, causing commit gaps and inconsistencies.

Environment

Stitch 

This article explains whether changing integration credentials or the host address for a database integration requires an integration reset in Stitch. It will also address key differences between key-based incremental replication and log-based incremental replication.

Changing Integration Credentials

Updating credentials (e.g., username or password) does not require an integration reset. Stitch will continue replicating data from the last saved bookmark values for your tables according to the configured replication method.

MySQL extraction encounters the following error: 

FATAL [main] tap-hp-mysql.main - Fatal Error Occurred - YEAR

Resolution

• Identify columns storing date/time values.
• Query for invalid years
  For example:
  

  YEAR(date_column) < 1 OR YEAR(date_column) > 9999

• Correct invalid records or replace them with valid defaults.
• If you cannot modify source data, deselect the problematic column in table settings in the integration.
• Consider enforcing valid ranges via application-level validation or MySQL constraints.
• If using MySQL zero dates (0000-00-00), adjust SQL mode or replace with valid dates.

Cause

This error occurs when the MySQL integration attempts to process a DATE, DATETIME, or TIMESTAMP field containing an invalid year value. Common examples include 0 or any year outside the supported range. The error message typically states "Fatal Error Occurred" followed by details about the invalid year or month value.

The underlying Python library used by the Stitch MySQL integration enforces strict date parsing rules. It only supports years in the range 0001–9999. If the source data contains values less than 0001 or greater than 9999, the extraction will error. This issue often arises from legacy data, zero dates (0000-00-00), or improperly validated application inserts.

Any column selected for replication that contains invalid date values will trigger this error.

Environment

Stitch 

Loading Error Across All Destinations

When Stitch tries to insert data into a destination table and encounters a NOT NULL constraint violation, the error message typically looks like:

ERROR: null value in column "xxxxx" of relation "xxxxx" violates not-null constraint

or

ERROR: null value in column "xxxxx" violates not-null constraint

Key Points

• The column referenced is usually a Primary Key (PK) field or a Stitch-generated system column(Qlik Stitch Documentation) such as _sdc_level_1_id.
• These _sdc_level_id columns help form composite keys for nested records and are used to associate child records with their parent. Stitch generates these values sequentially for each unique record.
• When combined with _sdc_source_key_[name] columns, they create a unique identifier for each row. Depending on nesting depth, multiple _sdc_level_id columns may exist in subtables.

Resolution

Recommended Approach

Pause the integration, drop the affected table(s) from the destination, and reset the table from the Stitch UI. If you plan to change the PK on the table, you must either:

• Drop the destination table and reload, or
• Modify PK constraints in the destination.

If residual data in the destination is blocking the load, manual intervention may be required. Contact Qlik Support if you need assistance clearing this data.

Cause

Primary Key constraints enforce both uniqueness and non-nullability. If a null value exists in a PK field, the database rejects the insert because Primary Keys cannot contain nulls.

If you suspect your chosen PK field may contain nulls, you can:

• Choose a different field as the primary key to avoid this error, or
• Review and update your source data to populate null records, ensuring data integrity—especially for fields used in a composite PK.

Environment

Stitch 

The NetSuite integration encounters the following extraction error:

[main] tap-netsuite.core - Fatal Error Occured - Request failed syncing stream Transaction, more info: :data {:messages ({:code {:value UNEXPECTED_ERROR}, :message "An unexpected error occurred. Error ID: <ID>", :type {:value ERROR}})}

Resolution

The extraction error message provides limited context beyond the NetSuite Error ID. It is recommend reaching out to NetSuite Support with the Error ID for further elaboration and context.

Cause

This error occurs when NetSuite’s API returns an UNEXPECTED_ERROR during pagination while syncing a stream. It typically affects certain records within the requested range and is triggered by problematic records or internal processing issues during large result set pagination.

Potential contributing factors include

• Data inconsistencies in specific records.
• NetSuite backend limitations or transient service issues.
• Large result sets combined with complex queries or filters, which increase processing complexity.

Environment

• Stitch