Table Structure Editor
The table structure editor keeps single-table metadata and a change draft in a persistent tab. DBX enables only operations that the active database capability can generate reliably and shows the final DDL before save.
Open the Editor
- Right-click a table and choose View structure or Edit structure
- Open from a column node and focus that column
- Open from an index node and focus that index
- Open from table information in the data grid
- Open the same table from Object Browser or a DDL action
The editor retains the active tab, scroll position, column widths, and local column order while you move between structure and data.
Structure Tabs
| Tab | Main contents |
|---|---|
| Columns | Name, type, length/precision, nullability, default, primary key, identity, charset, collation, comment |
| Indexes | Name, columns, type, unique state, included columns, filter, comment, and rebuild action |
| Foreign keys | Local columns, target table/columns, ON DELETE, and ON UPDATE |
| Triggers | Trigger metadata, source, and supported create/edit/drop actions |
| DDL | Current table definition or driver-generated structure SQL |
When the database does not provide a metadata class, the related tab is hidden, read-only, or displays a capability explanation.
Column Editing
Depending on database capability, you can:
- Add a column or insert after the current selection
- Drop, rename, and alter columns
- Change type, length, precision, scale, and database-specific length units
- Change
NULL, default, primary key, identity, charset, collation, and comment - Use quick picks for common default values
- Drag columns to change order
Column reorder has two meanings:
- MySQL and other databases with physical column-order DDL generate a real reorder
- Some databases save only the local display order in DBX without changing physical structure
New-table creation can use preset fields from settings for common primary keys, timestamps, or audit columns.
Indexes, Foreign Keys, and Triggers
Index capabilities vary by dialect and can include:
- Create, drop, or rebuild an index
- Standard, unique, and database-specific index types
- Included columns or filters on PostgreSQL, SQL Server, and similar databases
- Index comments where supported
- Automatic names for new indexes with editable values
Foreign-key editing covers column mappings and update/delete actions. Trigger editing depends on source retrieval and safe DDL generation; unsupported databases can still expose source or copyable DDL.
DDL Preview
Edits do not immediately change the database. Before save, DBX generates highlighted dialect-specific SQL such as:
ALTER TABLE ... ADD/DROP/RENAME/MODIFY COLUMN- Default,
NULL, primary-key, and comment changes CREATE INDEX,DROP INDEX, and rebuild operations- Foreign-key and trigger DDL
- Table-rebuild steps when SQLite requires them
Copy the complete DDL for code review or execution through a migration tool.
NULL, changing primary keys, physical reorder, and table rebuilds can lock tables or lose data. Review execution impact, backups, and rollback plans in production.Save Workflow
Read the latest structure
Confirm that columns, indexes, foreign keys, and triggers are loaded. Refresh first if another client recently changed the table.
Build a local draft
Add, edit, remove, or reorder objects. Deletions remain pending and are not executed yet.
Review DDL
Verify qualification, types, defaults, constraints, indexes, and statement order.
Execute and refresh
Execute after review. Production scope enters production-write confirmation again, and DBX reloads structure after success.
Dialect and Capability Differences
| Dialect/database | Typical behavior |
|---|---|
| MySQL / MariaDB compatible | Broad column properties, physical reorder, primary key, index, foreign key, and comment coverage |
| PostgreSQL / Gauss-compatible | Dialect-aware type/default/null/comment, included/filtered indexes, foreign keys, and related DDL |
| SQLite | Some complex column changes use a safe table-rebuild strategy |
| DuckDB | Supports common column and index operations with behavior distinct from SQLite |
| SQL Server | Column and index changes with dedicated syntax for defaults, included columns, and filtered indexes |
| Oracle / Dameng and similar | Oracle-style column, comment, and index DDL; irrelevant integer-length controls are disabled |
| ClickHouse / Manticore / InfluxDB and others | Only the verified implemented subset is enabled |
| JDBC/Agent | Maps through a recognized dialect and stays read-only when the dialect cannot be identified reliably |
Do not assume that every DDL feature is editable because a database can connect. Use Database Support and the actual editor controls as the current source of truth.
Concurrency and Recovery
- Drafts are based on metadata read when the editor opened and do not merge external schema changes automatically
- If execution fails, earlier statements may already have succeeded
- Atomicity of SQLite rebuilds and multi-statement DDL depends on database and driver behavior
- Refresh reloads structure and may require discarding an unsaved draft
- Read-only connections block save, and production writes require explicit confirmation every time
Recommendations
- Use the editor for focused, single-table changes
- Put copied DDL into version control and review for larger migrations
- Use Schema Diff to align environments
- Use Database Export or Scheduled Database Backups before risky changes
- Combine Field Lineage with application-code search before changing important columns