Hello,

I have a question about the upcoming End-of-Life of PostgreSQL 14 that has been announced last week (see https://www.postgresql.org/docs/release/14.24/)

Does anyone know if there will be an update that includes a newer DB version before we reach EOL for PostgreSQL 14 on November 12, 2026? As far as I'm aware, the most recent version of QlikSense still comes with PostgreSQL 14.22.2 included.

If not, do you have any recommendations on how to proceed? We do not want to risk running an outdated system database that cannot be patched.

If possible, we would also prefer not to migrate to a separate PostgreSQL installation as discussed e.g. in this thread: https://community.qlik.com/t5/Management-Governance/Moving-a-PostgreSQL-version-14-toward-version-17/m-p/2541205#M32534.

If there are no other options, I would be very interested in hearing from someone who has successfully moved to a separate DB installation and who is willing to share their experience.

Thanks!

I'm trying to setup a block to retrieve trust score information from datasets in my tenant. According to documentation I need to use a Qlik Cloud Services - Raw API Request and point to  

api/data-governance/trust-scores/results/data-sets/actions/filter

After running the automation this is the response

{ "response": { "status": 404, "body": { "error": "Unknown Service (url: https://mytenantid.us.qlikcloud.com/api/data-governance/trust-scores/results/data-sets/actions/filter)" } }, "external error": false }

I've tried using curl to call this endpoint externally and it works fine. 

Hello Qlik Community,

We would like discuss about a suspected issue in Qlik Replicate. After a source table is recreated and explicitly reloaded, Full Load completes successfully, but subsequent changes to that table are not captured. CDC resumes only after an additional Stop → Resume.

Environment

• Qlik Replicate: 2026.5.0.423.  Sourse and Target use same  Microsoft SQL Server 2019, Microsoft SQL Server (MS-CDC) 

• Task  Full Load + Apply Changes + Store Changes enabled. DDL action all ignored 
  
  

  The test uses two tables:

  • dbo.VersionTest — the table being recreated.

  • dbo.CdcHeartbeat — an unaffected control table. A stored procedure continuously generates committed updates to this table so that the task’s LSN position continues to advance.
    

  •  

  The heartbeat procedure remains running throughout the experiment, including periods when the Replicate task is stopped.

  VersionTest has a primary key and simple text/numeric columns, without LOB or rowversion columns. We reproduced this behavior in a laboratory while investigating replication recovery after BAS application table restructuring.

  Steps to reproduce

  1. Start the Replicate task and confirm that CDC works for both tables. Start the procedure generating continuous committed updates to CdcHeartbeat.

  2. While the Replicate task is running, drop dbo.VersionTest.

  3. Create a new table named dbo.VersionTestNG.

  4. Rename dbo.VersionTestNG to dbo.VersionTest. The table now has the original name but a different SQL Server object_id.

  5. Manually enable MS-CDC for the new dbo.VersionTest. Verify that changes to this table appear in the source cdc.dbo_VersionTest_CT.

  6. Stop the Replicate task and wait until it is Stopped. Mark VersionTest for Reload while the task is stopped, then select Resume Processing.

  7. Wait for Full Load to complete successfully. Execute and commit an UPDATE setting the test value to PROBE_A. This event appears in the source CDC table but does not appear in the target VersionTest__ct. Meanwhile, heartbeat changes continue reaching the target and advance the saved task position beyond the LSN of PROBE_A.

  8. Perform another Stop → Resume Processing, without an additional Reload.

  9. Execute and commit another UPDATE setting the value to PROBE_B. This change is captured successfully. The target VersionTest__ct contains the transition PROBE_A → PROBE_B, but the previously missed event that changed the value to PROBE_A is not recovered.

  Expected behavior

  After an explicit Reload refreshes the recreated table’s metadata, CDC should resume for that table.

  If this DDL scenario requires additional recovery steps, we need a documented, supported procedure that prevents missed changes and clearly identifies when capture remains inactive.
  

  Observed mechanism

  At the first Resume, the capture component detects the missing old object and removes its registration. Reload subsequently refreshes the metadata for the new object, but the new CT is not added to the running capture component’s polling list.

  The additional task restart establishes the correct registration and restores polling.
  

  The task continues processing other tables and advancing its LSN while capture of VersionTest remains inactive. This creates a gap in the change history, which is critical for downstream historical processing.

  An additional Stop → Resume restores future CDC processing but does not recover the missed interval. The current workaround therefore requires keeping writes to the recreated tables paused until Reload, the additional restart, and CDC verification have completed.

  
  what is best supported recovery procedure after replacing a source table with a new object under the same name?