Import SQL / DDL and Migration Scripts

DbSchema can import a design model from external files — including CSV, Excel, and SQL DDL files containing CREATE TABLE statements — or from a whole folder of SQL migration scripts, such as the ones Flyway applies. After import, the schema is displayed as a visual diagram and saved to a .dbs model file.

Importing from a File

Open the importer via Model → Import from External Format, then leave Source on Files. A file picker lets you select one or more source files.

After selecting the file, map each column in the input data to its role in the schema:

• Schema — the schema/database name
• Table — the table name
• Column — the column name
• Type — the data type
• Length — the column length or precision
• Nullable — whether the column allows nulls

DbSchema loads the data into an internal H2 database, parses it, and generates a new design model with the inferred tables and columns.

A file holding SQL DDL takes a different route: DbSchema opens it in an SQL Editor and parses its CREATE TABLE statements straight into the model, with no column mapping step.

Importing a Folder of Migration Scripts

Set Source to Folder with migration scripts to point DbSchema at a migrations folder instead of at single files — the db/migration folder of a Flyway project, or any folder of numbered .sql files. DbSchema reads every script in the order a database would have applied them and builds one model out of the result: a script that alters a table an earlier script created is applied on top of it, exactly as it would be on a real database.

Nothing is executed. The scripts are read as text, and no database connection is needed.

The Replay Order

The dialog lists every script it found, in the order it will read them, so you can check the order before importing. DbSchema recognizes Flyway's naming:

A folder that follows no convention still imports: scripts DbSchema cannot read a version from are applied in natural file-name order, so 2_x.sql precedes 010_x.sql.

Options

• Sub-folders — also read the scripts of every folder below the chosen one.
• Repeatable (R__) — include the scripts re-applied on every migration, usually views and functions.
• Undo (U__) — include the scripts that reverse a versioned one. Leave this off: replaying an undo script after the script it reverses takes the model back apart. It is there for folders that use U as a version prefix for something else.

Target

• New Model — build a new design model, in the database syntax chosen under DBMS.
• Current Design — compare the replayed scripts against the model you already have. DbSchema opens the synchronization dialog, where you choose change by change what to take over.

What Is Imported

The parser reads the schema, not the data. CREATE, ALTER, DROP, COMMENT and the statements around them shape the model; INSERT, UPDATE and DELETE are passed over, so seed data in a migration script changes nothing. Flyway placeholders such as ${schema} are not substituted, and a script relying on them may not parse.

When a script holds a statement DbSchema cannot apply, the import does not stop: the rest of the file and every file after it are still read, and a report at the end names each file with the number of statements it could not apply. A clean run shows no report.

Configurable Model Exporters

Access the export dialog from Model → Export As…. You can define a custom exporter with:

• Operations — iterate over tables, columns, foreign keys, or indexes.
• Filters — conditions that must be met before a field is included (e.g. skip nullable columns).
• Fields — the values to export for each iterated object.
• Patterns — a text template where ${value} is replaced with the actual field value. Patterns let you produce comma-separated files, tab-delimited files, XML, or any other text format.

Patterns can be set globally for the entire exporter, per tab/section, or per individual field.

Export via Groovy Script

For maximum flexibility, export the design model using a Groovy script in the Automation Scripts dialog (Tools → Automation Scripts).

The built-in Model to CSV File example script is a good starting point. Copy it, paste it into an SQL Editor, switch the language from SQL to Java Groovy, and customise it to export exactly the fields you need.

Groovy is 100% compatible with Java, so any Java knowledge applies directly. The full DbSchema API is linked from the Automation Scripts dialog and documented at DbSchema API.