Command-line mode

A saved job holds both connections, the table selection and the options. Run it by name. There is nothing else to pass. The workflow guide covers the job screen.

• Name the job
• Where jobs are stored
• Run it
• Checks before an unattended run
• Output and logs
• Exit codes
• Running several jobs
• Scheduled jobs
• Passwords
• Running the engine yourself
• Command files

Name the job

A job saves itself from the moment Setup creates it. Its name is at the top of the window. That is the name you run.

To rename it, click the name and select Rename….

Where jobs are stored

<Product> is the product's own folder: the two databases joined by a hyphen, such as SQLite-MySQL, MSSQL-PostgreSQL or Access-SQLite. DBConvert for Excel and DBConvert for FoxPro use Excel and FoxPro.

DBConvert for SQLite & MySQL also runs jobs and command files that older builds saved in %LOCALAPPDATA%\DBConvert\jobs\.

The saved job is used when present. A .jsonl command file with the same name is used only when there is no saved job.

To see a job's file, open Jobs in the left rail, select the job and expand Job file. It shows where the file is and its text, read-only. Copy puts the text on the clipboard, for example for a message to support. The file holds references to connections, never passwords.

Run it

"C:\Program Files\DBConvert\DBConvert for SQLite and MySQL\DBConvert_SQLite_MySQL.exe" --run-job "Nightly orders"

Each pair installs its own executable under %ProgramFiles%\DBConvert\. The Start menu shortcut opens that folder's application.

--run-job is matched exactly, in lower case.

DBConvert_SQLite_MySQL.exe /Session:"Nightly orders"
DBConvert_SQLite_MySQL.exe /Session: "Nightly orders"

Checks before an unattended run

Command-line and scheduled runs check the saved table selection before copying. They follow the job's Include / Skip choice. Older jobs with an explicit table list keep that selection.

The run checks the tables as the Tables step does. A table with a blocking problem, such as two source tables mapped to one destination table, is handled by the job's scheduledCheck setting:

• "strict": the run is refused before anything is written. Exit code 1. The app saves new jobs this way.
• "soft": those tables are left out and the rest run. Exit code 2. A job saved before this setting existed runs this way.

To change it, edit the job file.

A system database selected as the destination also stops the run. Open the job in the app to correct the destination or table selection.

Output and logs

No application window opens. The run writes to the console it was started from:

2026-08-24 12:47:21  === job run: Nightly orders ===
2026-08-24 12:47:23  Copying data for table 'orders'.
2026-08-24 12:47:25  Elapsed 00:00:02. Inserted: 41902 of 41902.
2026-08-24 12:47:25  run finished: ok (exit 0)

Redirection works as usual: --run-job "Nightly orders" > run.txt. Under Task Scheduler, a shortcut or Explorer there is no console, and the log is the only record. Every run is appended to it.

Exit codes

Code 2 is not a failure. Scripts usually branch on it separately:

@echo off
set APP=C:\Program Files\DBConvert\DBConvert for SQLite and MySQL\DBConvert_SQLite_MySQL.exe

"%APP%" --run-job "Nightly orders"

if %ERRORLEVEL% EQU 0 echo done
if %ERRORLEVEL% EQU 1 (echo FAILED & exit /b 1)
if %ERRORLEVEL% EQU 2 echo finished with rejected rows - see the log

Read the code from a batch file, not from an interactive prompt: Windows does not make a shell wait for a windowed program, so the prompt returns before the run finishes and %ERRORLEVEL% still holds the previous value.

Running several jobs

@echo off
set APP=C:\Program Files\DBConvert\DBConvert for SQLite and MySQL\DBConvert_SQLite_MySQL.exe

"%APP%" --run-job "Customers"  || exit /b 1
"%APP%" --run-job "Orders"     || exit /b 1
"%APP%" --run-job "Archive"    || exit /b 1

|| stops on code 1 and on code 2. To continue after rejected rows, use the if %ERRORLEVEL% form above.

Scheduled jobs

To schedule the open job:

1. On Execution, click Schedule….
2. Choose Frequency and Start time.
3. Click Save schedule.

The job runs while you are logged in to Windows, even with the app closed. The same dialog shows the next and last run, and has Run now and Remove. Open log folder shows what each run did.

The schedule is a Windows Task Scheduler task. It runs:

DBConvert_SQLite_MySQL.exe --run-scheduled "Nightly orders"

Same exit codes.

Keeping a destination in sync

Every N minutes repeats a sync job, so the destination follows the source all day.

A Convert job cannot repeat this way: each run would copy the same rows again. For a Convert job the list shows Every N minutes (sync jobs only), and the option cannot be chosen.

If a run is still going, the next one is skipped. The one after it starts on time.

One run of a job at a time

A job runs once at a time, wherever it is started: the app, --run-job or a schedule. A second start while the first runs is refused:

the job 'Nightly orders' is already running (from the window, a schedule or the command line): this run was not started

From the command line and in a schedule, that start exits with code 1, and the line goes to the job's log.

Passwords

A job saved by the app holds no password. Connection passwords are read from the Windows credential store at run time. The job must therefore be saved on the machine, and under the Windows account, that will run it.

A command file written by hand can contain a password in plain text. That file is a secret: keep it out of version control, or hold the password in the CI secret store and write the file at build time.

If a secret is missing, the run reports which connection, then continues with what the file holds. A password that was required fails at connect time with the server's own error.

Running the engine yourself

Every run goes through the same engine: a run started in the app, --run-job and a scheduled task. It sits beside the app, for example DBConvert_SQLite_MySQL_Engine.exe. Call it yourself when you need a switch the app does not pass.

"C:\Program Files\DBConvert\DBConvert for SQLite and MySQL\DBConvert_SQLite_MySQL_Engine.exe" run "%LOCALAPPDATA%\DBConvert\SQLite-MySQL\jobs\Nightly orders.json" --product sqlite-mysql

It takes the job file, a .json or .jsonl, and --product: the product's folder name in lower case, such as sqlite-mysql or mssql-db2.

Without a registration and without --trial, the run is refused. The exit codes are the ones above.

Every run also writes <job>.lastrun.json beside the job file. The app shows it as the job's last run. A script can read it instead of the log:

{
  "at": "2026-11-02T02:00:41.512Z",
  "deleted": 0,
  "errors": 12,
  "exit": 2,
  "firstError": "Duplicate entry '1042' for key 'PRIMARY'",
  "inserted": 41890,
  "renamed": 0,
  "result": "errors",
  "rowsRejected": 12,
  "secs": 18.4,
  "skipped": 0,
  "started": "2026-11-02T02:00:23.101Z",
  "strict": true,
  "tables": 3,
  "tablesFailed": 0,
  "updated": 0
}

result is ok, errors, cancelled or failed. firstError is the first error. A run refused before it started also has refused, the reason.

Command files

Create and edit saved jobs in the app. The following format is for .jsonl command files from older builds or files you write yourself.

One JSON object per line, executed in order. start comes last; a file without it exits 1 with no start command in the file.

A minimal job

The shortest file that runs. Everything not named here takes the engine's default:

{"action":"connect","role":"source","dbType":"sqlite","path":"C:\\data\\shop.sqlite","id":1}
{"action":"connect","role":"dest","dbType":"mysql","host":"127.0.0.1","port":3306,"user":"root","password":"secret","database":"shop","id":2}
{"action":"setOptions","table":"people","copyStructure":true,"copyData":true,"copyIndexes":true,"copyForeignKeys":true,"overwrite":false,"truncate":false,"id":3}
{"action":"start","tables":["people"],"threads":1,"operation":"convert","id":0}

Save it in the jobs folder as My job.jsonl and --run-job "My job" runs it.