Descrizione del problema:
Quando creo una sottoscrizione (Subscription) su un foglio/oggetto che genera un PDF di più pagine, il file allegato alla mail automatica a volte arriva incompleto, con pagine mancanti rispetto a quelle attese. Il problema è incostante: alcuni invii risultano completi, altri no, con lo stesso identico foglio e le stesse impostazioni.

Passaggi per riprodurre:

1. Creo una sottoscrizione su un foglio con una tabella che genera più pagine in PDF (verificato manualmente con "Scarica")
2. Uso "Invia ora" o attendo l'invio programmato
3. Il PDF ricevuto via mail ha meno pagine di quelle previste

Comportamento atteso: il PDF inviato via sottoscrizione dovrebbe sempre contenere tutte le pagine, come nel download manuale.

Ambiente: Qlik Cloud, sottoscrizione tramite provider email SMTP configurato

I am planning to develop a capsule supplement and I am currently looking into different manufacturing options. I am trying to understand what I should check before choosing a capsule contract manufacturer.

Should I mainly focus on manufacturing quality, formulation support, minimum order quantities, certifications, packaging options, or production capacity? I would also like to know whether it is better to work with a manufacturer that specializes in capsules or one that offers multiple supplement formats.

If anyone has experience with capsule supplement manufacturing, what factors did you consider before selecting a manufacturer?

I have 2 questions:

1) Does ASM Log Reader alter redo log files or only reads them? 
2) Confirmation of whether Qlik Replicate alters state of ASM and its files or not

3) Why it is needed to grant SYSASM privileges? Is it possible to work with ASMOPER privilege?
4) List of commands/calls that are executed by Replicate while working with ASM (including which of the procedures from DBMS_DISKGROUP package are used and in what modes)?

Hello,

I have configured a Log Stream task that reads from an Oracle database.

The task failed following a database maintenance activity that temporarily disabled the ARCHIVELOG log mode.

After ARCHIVELOG was re-enabled, I resumed the Log Stream task. However, the task is unable to complete the resume successfully and remains in the recovering state.

When reviewing the task log file, I can see the following error messages:

• Unable to get table definition for table '0'
• add table desc to the metadata manager has failed

I found the following link in the Qlik Community, which explains that the error retrieving the table definition should be caused by a DDL operation that modified the structure of a table: https://community.qlik.com/t5/Official-Support-Articles/SOURCE-CAPTURE-E-Unable-to-get-table-definition-for-table-0/ta-p/1809603.

I tried increasing the task verbosity to understand which tables might have been affected by this change. Specifically, I increased the verbosity of the SOURCE_CAPTURE, SORTER, METADATA_MANAGER and TARGET_LOAD parameters. However, I cannot find any indication in the log file of which tables were affected by the modification.

Is there any way to identify in Qlik Replicate which tables were affected by the DDL operations that are causing a mismatch with the table metadata registered by Qlik Replicate?

Thank you in advance for your support.

Best regards

Quick one for anyone managing reload chains in Qlik Cloud: there's a Visual Task Chain Viewer now built into the Tasks section of the Analytics activity center, and it's genuinely useful.

Instead of clicking into each task in a chain to piece together what depends on what, you get a graph. Click the dependency icon next to a chained task and it opens with that task highlighted, upstream and downstream tasks laid out around it, and each connection labeled by trigger type: on succeeded, on failed, or on finished.

A few details that matter in practice:

• Task cards in the graph show the last run status, so a failed link is easy to spot.
• You can set a different task as the anchor to re-center the view, then reset back to the original.
• From a task card you can view details, edit the chain, run the task now, or activate/deactivate it, all without leaving the graph.
• Permissions still apply. If you can't access a task in the chain, you'll see the dependency but can't manage it.

I put together a full walkthrough on the Data Voyagers channel covering navigation and a couple of real troubleshooting scenarios. Link's here if you want to see it in action: https://youtu.be/GvG_wqvMlZ0

Curious if others have run into cases where this would've saved them time. Drop a comment if you've used it yet.

Regards,

Mark Costa

Hi,

I have 2 questions hopefully you can help with.

1. I'd like to know if the bulkArraySize internal parameter is applicable to CDC as we are trying to maximise a client's performance during periods in which the source database experiences high volumes of changes. I've seen articles like this one. However, it looks like it only mentions that it is for Full Load and not for CDC.

2. My second question is can we enable "Copy redo logs to a temporary folder" and increase the number of concurrent ASM read threads at the same time? Is it redundant to do both at the same time?

For context, this Qlik Community article mentions that enabling the setting "Copy redo logs to a temporary folder" on the Oracle source endpoint should increase performance. Can I stack these over one another to increase performance?

Help with this is appreciated. Thank you.

Kind regards,

Mohammed

We have a busy source table and have lots of transaction every minutes. However we don't see the table gets replicated under CDC into target. Source is MySQL 8.0.45 on premise while target endpoint is Snowflake AWS.

We have enabled target apply to verbose however it's not showing up as target apply in the logfiles. It only has source_capture.

23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]T: Event header: type=16, timestamp=2026-09-15 12:17:52 (1789489072), event_len=31, pos=1069454637, next_pos=1069454668 (mysql_endpoint_capture.c:1195)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: Event = 16, file_suffix=8666 (mysql_endpoint_capture.c:3072)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: Resuming=0, EventPosInFile=1069454637, EventHeaderNextPos=1069454668 (mysql_endpoint_capture.c:3097)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: Event timestamp '2026-09-15 12:17:52' (1789489072), pos 1069454637 (mysql_endpoint_capture.c:3148)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]T: > XID_EVENT (mysql_endpoint_capture.c:3201)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: Send COMMIT (7) record, record id -1795445488, stream position '$.008666:1069454637:-1:1069454668:37221256041509:$.008666:1069454456' (mysql_endpoint_capture.c:3722)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: read_next_binlog_event: next_pos=1069454668, curr_file=LUSQTTNDB04A-bin.008666, curr_file_len=1069454668, last_file=LUSQTTNDB04A-bin.008666, last_len=1069454668 (mysql_endpoint_capture.c:973)
23898836: 2026-09-15T12:17:52:393625 [SOURCE_CAPTURE ]V: Wait for new events... (mysql_endpoint_capture.c:981)
23898836: 2026-09-15T12:17:52:409223 [SOURCE_CAPTURE ]T: Wait minimum 5 seconds for next poll (mysql_endpoint_capture.c:994)

Hi,

I read a community post which said that uncommitted transactions on the source would result in source latency to increase on the task until the transaction is complete. However, I tested this by creating an uncommitted transaction on the source Oracle database yet I was unable to recreate this behaviour. I am on QR 2025.11.0.437. Why is this happening? Is this the expected behavior?

Help with this is appreciated. 

Thank you,

Mohammed