The Settings tab of a Writeback table holds its Sync Log, the record of every run of that table. Use it to start a run by hand and to see what each run wrote, and why a run failed or was skipped.
When the request goes through, the window closes and Synchronization started appears. The new run joins the log, and the success confirmation appears only once its entry is visible there.
The date you choose is recorded as the run's Snap Date. To run the table on a schedule instead, see Run, schedule and monitor Writeback.
Starting a run needs Execute/Abort WriteBack Objects. See Writeback permissions for the full list.
The log shows one row per run of this table.
| Column | What it shows |
|---|---|
| Log ID | The identifier of the run. |
| Snap Date | The date and time the run was recorded for. |
| Status | The state of the run. See the statuses below. |
| Note | Extra detail, such as why a run was skipped. |
| Start and Finish | When the run started and ended. |
| Processed Rows | How many rows the run sent. |
| Client Addr | The address the run was started from. |
| Error | The text of a failed run. |
You can search and filter the log, show or hide columns, and set the page size to 20, 50, 100 or 500 rows; the default is 50 rows a page. An (Empty) filter choice matches blank values. Refresh data reloads the log, and the export downloads it as a file named etl_log_ plus the table's identifier.
While a run is still active, a Syncing badge shows next to the Sync Log heading and the log refreshes by itself every 7 seconds, so Status, Processed Rows and Error stay current. When the run ends, the badge clears.
Until the table has run, the log reads No synchronization logs found.
| Status | Meaning |
|---|---|
| Pending | The run is queued and has not started. |
| Running | The run is in progress. |
| Finished | The run completed. |
| Skipped | The run sent no rows; the Note column gives the reason. |
| Error | The run failed; read the Error column. |
| Aborted | The run was stopped before it finished. |
The Note of a skipped run starts with Skip Reason:, followed by one or more reasons:
The Synchronize button is off while a run of the table is already active. The request is refused when the table is not deployed, while the table's workflow is running, and when the workflow is scheduled to start within the next hour. Wait for the run to finish, save the column mapping, or use the scheduled run.
It is recorded as the run's Snap Date in the log. A run you start by hand ignores the table's synchronize option; a run started by the workflow follows it.
Synchronization started appears, and the new row joins the log. The log keeps you posted while the run works.
While a run is still active, the log refreshes every 7 seconds so the Status, Processed Rows and Error columns stay current. Refresh data reloads the log at any time.
In the Processed Rows column. A skipped run sends no rows; its Note says why.
Read the Note: it starts with Skip Reason: and lists Synchronize Option Is Disabled, Table Is Not Deployed or Node Already Run. For the first two, map at least one column on Map columns and click Apply. For Node Already Run, start a new run.
Yes. Every run of the table is in the log, whether the workflow started it or you did. A workflow run follows the table's synchronize option.
When a run cannot be started, you see Failed to synchronize. in the Synchronize Table window, or a Failed to synchronize table notice. Click Synchronize again. If it keeps failing, see Writeback troubleshooting.
Use the export on the log toolbar. The file is named etl_log_ plus the table's identifier.