Analyses each table in the source database before migration
begins.
Identifies conditions that may cause errors, data loss, or unreliable
resume behaviour, so you can decide how to proceed.
The analysis runs automatically when the dialog opens.
Results are shown in a list with four columns: Table,
Severity, Issue, and
Detail.
| Severity | Meaning |
|---|---|
| OK | No issues found. Table migrates normally. |
| Info | Noteworthy condition; migration completes without data loss. |
| Warning | May cause data loss or make resume/re-run unreliable. Review before continuing. |
Migration of tables without a primary key is strongly discouraged. See Tables Without a Primary Key below.
Uses adaptive strategy: values up to the inline
threshold are sent in the JSON batch; values above it are uploaded as
separate files via multipart POST.
The primary key ensures re-running does not duplicate rows.
The inline threshold is adjusted automatically from the server’s
max_allowed_packet and memory_limit when
Get Server Information is run (default: 1024 KB). The
active value is shown in the Detail column.
Values up to the inline threshold are sent in the JSON batch — the
same threshold as the adaptive strategy above.
Values above the threshold are set to NULL — file
upload is not possible without a primary key to identify the target
row.
The active threshold value is shown in the Detail
column.
Migrating a table without a primary key carries risks that cannot be fully mitigated at the tool level. Both Warning cases above share the same two problems:
Risk 1 — re-running duplicates rows. EDB2MySQL uses the primary key to detect whether a row already exists on the target. Without a primary key, there is no conflict detection: running migration a second time — or running it again after a partial failure — appends all rows again, producing duplicates.
Risk 2 — resume after interruption is unreliable. Without a primary key, row order is not guaranteed to be consistent between runs. If migration is interrupted and resumed, the offset saved may not correspond to the same physical row, and rows may be missed or duplicated.
Risk 3 — BLOB/CLOB truncation (tables with BLOB/CLOB columns only). File upload of large values requires a primary key to route the data to the correct row. Without one, any value above the inline threshold is silently stored as NULL.
Add a primary key to the EDB table before migrating. A surrogate integer column is sufficient:
-- Step 1: add an IDENTITY column and declare it as primary key in one statement;
-- EDB populates it automatically for all existing rows
ALTER TABLE "MyTable"
ADD COLUMN "_pk" INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1) NOT NULL,
ADD CONSTRAINT "PK" PRIMARY KEY ("_pk");
-- Step 2: convert to a plain integer to avoid unnecessary GENERATED column warnings during conversion
ALTER TABLE "MyTable"
ALTER COLUMN "_pk" AS INTEGER NOT NULL;After migration is complete and verified, the column and its primary key constraint can be dropped from the MySQL/MariaDB target in one statement if they are not wanted in the final schema:
ALTER TABLE `MyTable`
DROP PRIMARY KEY,
DROP COLUMN `_pk`;If adding a primary key to the EDB table is not possible, proceed with the understanding that the risks above apply and plan accordingly (single run only, no resume, verify row counts after migration).
50,000 or more rows. Migration completes normally but may be slow.
The summary line shows the count of Warnings and Info items.