Data Access and Operations

This page collects the connection, sync, logging, and troubleshooting questions that support teams have to repeat most often. It does not replace connector-specific manuals; it helps you decide whether the problem is more likely in the connection, the sync strategy, or the runtime environment.

Can a data connection be used as a data-integration output target?

Yes, but "the connection works" is not enough. The target connection must actually support write operations.

In practice, check at least these two things:

1. The target connection is configured with write operations allowed
2. The target database account really has write privileges

If you can browse tables in the UI but batch sync still cannot write to the target, do not start with the sync task. First confirm that the target connection is not read-only in practice.

Related docs:

• Data Connections
• Batch Sync

Why does an incremental sync suddenly turn into a full sync?

A common reason is schema change in the source table.

When the system detects that the schema used by incremental sync no longer matches, it may trigger a full sync. The fastest way to confirm this is not guessing but looking for logs such as:

trigger full sync for schema mismatch

If sync duration or target load matters to you, this log pattern should become part of your normal troubleshooting habit. Many "why did incremental suddenly become slow?" cases are actually "it is no longer incremental."

Why does syncing from built-in PG to MySQL fail with lock timeout?

The common reason is not that sync is broken. It is that the target-side table is being held by another transaction.

If you see something like:

ERROR: canceling statement due to lock timeout

check first:

1. Whether another query or transaction is holding the target table
2. Whether there are long-running connections in idle in transaction

In PostgreSQL, a common first query is:

select * from pg_stat_activity where state != 'idle';

Figure out who is holding the table before repeatedly rerunning the sync task.

Why does Mongo BI Connector say mongodb schema not yet available?

This usually does not mean your connection parameters are wrong. It usually means Mongo BI Connector is still sampling schema.

Mongo BI Connector is not always query-ready immediately after startup. It needs time to sample data and infer schema. That timing depends on data volume, table size, and MongoDB load.

A typical log pattern is:

sampling MongoDB for schema...
mapped schema for ...

The first message means schema sampling started; the second means sampling finished. If you only see the first one, waiting for sampling is usually more appropriate than changing the connection config right away.

When should I use an API data source instead of a normal database connection?

Use an API data source only when the source is naturally HTTP/API-based, or when you truly need custom request logic.

If the source is already a standard database such as MySQL, PostgreSQL, or SQL Server, prefer the native database connection first because:

• configuration is simpler
• performance and stability are usually easier to control
• you do not have to maintain the API definition file yourself

You only enter API-data-source territory when you truly need custom logic such as getApiName, setOptions, getPathTables, and fetchTableData.

For data-access problems, should I start with connector docs, sync docs, or software configuration?

A practical rule:

Symptom	Start with
Cannot connect to the database / validation fails	Connector-specific docs and network reachability
Connection can be created, but sync fails	Batch Sync and target write permissions
Sync logic behaves unexpectedly	Execution history, task logs, and sync strategy
The same config works in one environment but fails in another	Then check proxy, timezone, and software configuration

Once the problem requires log keywords to classify, it is usually no longer just a simple parameter typo.

Further reading:

• Data Connections
• Batch Sync
• Software Configuration Issue