Opened to review and run script for merge, replace and delete actions performed using 
merge to right, 
merge to left, 
replace to right, 
replace to left, 
delete left and 
delete right toolbar buttons.
It is opened from Object list and Table structure diff tabs to review scripts for processed database objects:
Dialog header:
Please review the merge script below and click Run to execute this script or copy it to clipboard/file for later use.
Warning: Script execution does not make any backup, please make sure that you've done it yourself if needed.
Target database: {Database display name}
Execution status: {Status}
Besides the 'no backup' warning, the header can include a few more warnings, depending on the script content and free session mode. If more than one applies, it shows a "Warnings:" heading followed by a bulleted list. Here are the remaining warnings:
- Table structure changes (deleted columns) may affect existing data.
- Some table definitions could not be fully read, script may lose comments or unrecognized parts.
- Some tables can be shadow tables of virtual tables, any changes can be undesirable.
- Execution stops when your free session expires, partial execution may occur.
The deleted columns warning is shown when the script drops a column, together with its data. Unlike other DBMS, a changed column type is not included here: SQLite can keep any value in any column (for STRICT tables, an incompatible value fails the merge instead).
The incomplete tables warning is shown when the script changes a table whose definition could not be fully read. The script is built from the table definition as the application understands it, not from the original CREATE TABLE text. So comments and the parts that were not recognized are not included in the script. Such tables are marked in the Object list and Table structure diff tabs.
The shadow tables warning is shown when the script changes a table whose name starts with the name of a virtual table and an underscore. Such a table can be a shadow table that stores data of the virtual table, and changing it can break the virtual table. Such tables are also marked in the Object list and Table structure diff tabs.
Dialog footer:
☐ Stop on first error (contraint violation, etc.) [ Run ] [ Close ]
The rest of area is divided into 3 major sections:
Script is truncated for better performance.with a Show all button. If first sub-item is more than 10k chars, then it is included without truncation. Even if truncated to 10k, Save will produce a file with a whole text, and Copy - with a text truncated to 1 million chars. Show all is not availabe during script execution.
For detailed analysis please review individual child items in the Script structure panel.
To view full script, click Show all.
This dialog is also shown from the Data diff and Batch data diff tabs to review scripts for data merge/delete actions:
For data merge/delete, this dialog contains additional elements:
Row-level changes: expected {row count}It is a number of single-row INSERT/UPDATE/DELETE statements based on selected rows or tables. This count does not include results of batch statements like INSERT INTO x SELECT * FROM y. After script execution, this section also includes counts of processed and failed rows. Processed row is the script item processed by the database. For example, if we have a transaction, 5 rows to process, 4th row fails, then we have expected = 5, processed = 4 and failed = 1. Failed transaction is rolled back, no actual changed in database, but we still have 4 processed rows.
Run button tries to execute all script items one by one. In case of error:
Script copied or saved using Copy and Save buttons can be executed by other tools, for example by the sqlite3 command line shell. But these tools may process errors differently than the Run button. For example, by default sqlite3 does not stop on error, it just reports it and executes the next statement. And a statement that fails inside a transaction does not roll back this transaction, so the next statements continue to change the database and the final COMMIT saves these changes.
This is especially important for table changes that are made by re-creating the table (see Table structure diff). If copying of rows into the new table fails, then sqlite3 still drops the old table and commits the transaction, and table data is lost.
So please make sqlite3 stop on the first error. Use the -bail command line option:
sqlite3 -bail database.sqlite < script.sql
or run .bail on before the script in an interactive session. When sqlite3 stops on error, the transaction is not committed, and it is rolled back when sqlite3 exits. The .bail command can not be added to the script itself, because it is a sqlite3 command, not SQL, and Run button would fail on it.
If other tools are used, please check how they process errors inside transactions.
