Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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:
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:
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:
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
staged_time = 05:01:44 to be missed due to transaction commit timing if the incremental job captures its watermark before the commit completes?Any insights would be greatly appreciated.
Thanks!
Hello everyone,
My Qlik Replicate version is 2024.5.0.563.
Earlier, I used Repuictl.exe to configure the root_url parameter and changed the default value from "attunityreplicate" to "abc" (command shown below). However, after restarting the Qlik Replicate service, the URL still contains "attunityreplicate" instead of "abc".
Could you please help me understand what might be causing this issue? Is there any additional configuration or procedure required for the root_url setting to take effect?
Thank you.
Repuictl.exe configuration set --root_url "abc"
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
Qlik is a Leader in the IDC Events/Global Events MarketScape: Worldwide Data Intelligence Platform Software 2026 Vendor Assessment
Here’s your agentic AI readiness check. (Got Qlik? You're closer than you think.)
Set your course for six weeks of expert-led sessions on data, analytics, and AI — available on demand.
Built for the builders: Modern data engineering is AI powered — and engineer led.
The pilot-to-production gap is real. From fragmented data to governance gaps Qlik and AWS break down what’s holding your enterprise AI back — and how to solve them.
Your journey awaits! Join us by Logging in and let the adventure begin.