A SQL backup can contain statements for several tables, while an application’s “Import data” screen may be designed for importing data into one selected table. If the screen rejects a multi-table backup, the problem may be a mismatch between the file and the import feature—not necessarily a damaged backup.
This guide explains how to identify that mismatch, test it safely, and choose an appropriate import route. The supplied issue identifies a reported problem in the dbx project, but its record does not establish the exact error, affected version, or a confirmed fix. Treat the examples below as diagnostic patterns, not as a reproduction of that report.
Recognise the symptom
You may be using a database-level control labelled “Import data” and selecting a SQL dump that contains statements for multiple tables. The import may fail, process only the selected table, or report an error. Those outcomes can have different causes, so first establish what the feature is meant to import and what the file contains.
A user interface label alone is not enough to determine the import scope. Check the control’s help text, documentation, and selected target. In particular, distinguish between:
- Table-level import: a file intended to load data into one existing table.
- Database-level SQL execution: a script containing statements that may create or modify multiple tables and other database objects.
- Backup restoration: a tool or documented procedure intended to restore a database dump, potentially with its schema and data.
Minimal example of the mismatch
Consider this illustrative SQL file:
CREATE TABLE customers (
id INTEGER PRIMARY KEY,
name TEXT
);
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
customer_id INTEGER,
total DECIMAL(10, 2)
);
INSERT INTO customers (id, name) VALUES (1, 'Asha');
INSERT INTO orders (id, customer_id, total) VALUES (10, 1, 25.00);This script creates and populates two tables. If an import screen expects a file for one selected table, it may not accept the script as a whole. The example demonstrates why scope matters; it does not show the exact format or behaviour of dbx.
Likely causes
1. The import feature has a narrower scope than its label suggests
The interface may sit within a database view but still operate on a selected table. Look for a table selector, a requirement to choose a destination table, or documentation that describes importing rows rather than executing arbitrary SQL.
2. The file is not in the format that the control expects
Some import controls accept structured data files for a table; others accept SQL. Even when a control accepts SQL, it may expect a particular statement structure. Check the accepted formats and any restrictions before changing the backup.
3. The SQL dump depends on a different database engine or environment
A dump can contain engine-specific syntax, settings, or object definitions. A script produced for one database system may not run unchanged on another. Confirm the source and destination database types and consult their current documentation.
4. The destination is not ready for the script
The script might create tables that already exist, rely on a particular execution order, or refer to objects that are missing. These are possibilities to investigate, not facts established about the reported issue.
5. The application version or import mode differs
Behaviour can change between versions or between separate import screens. Check the installed application version and the documentation for that version. Do not assume that advice for another release or a similarly named feature applies.
Safe diagnostic path
- Keep the original backup unchanged. Make a working copy and record where the backup came from. Avoid experimenting against production data.
- Inspect the file without executing it. Identify whether it contains statements for one table or several. Check whether it includes schema changes, data inserts, or other database operations. Do not share a dump publicly if it contains private data or credentials.
- Confirm the import target and accepted format. In the application, note whether a table is selected and whether the feature describes importing rows, running SQL, or restoring a database. Read documentation for the installed version rather than relying only on the button label.
- Check the database environment. Confirm the destination database and whether the backup was created for the same database engine. Look for prerequisites such as existing tables or required permissions in the relevant documentation.
- Try a disposable environment first. Use a temporary database or a copy of the destination. This lets you determine whether the issue is the file, the import feature, or the target state without risking valuable data.
- Capture the useful details. Record the application version, database type, selected import screen, file format, and complete error message. Remove secrets and sensitive row data before sharing logs or examples.
Choose an import route that matches the file
If the application provides a documented database-level SQL execution or restore workflow, use that for a multi-table dump, provided the workflow supports the dump’s format and database engine. Confirm the target database carefully before running it: a backup script can create or alter objects and insert data.
If the only supported route is table-level import, follow its documented format and import one table at a time only when that is appropriate for the backup. Do not split a SQL script mechanically without checking dependencies and statement order. A table’s data may rely on schema definitions or related records elsewhere in the file.
Before any import that could overwrite or modify existing data, arrange a recoverable backup of the destination and review the application’s documented restore procedure. If the project does not document a safe route for the file, pause rather than guessing at a command or running the script on production.
Verify the result
After importing in a disposable environment, check that:
- All expected tables are present, if the chosen workflow is meant to create them.
- The expected rows exist in each relevant table.
- Relationships and other required database objects are present where applicable.
- The application can read the imported data through its normal workflow.
- The import did not create unintended duplicate tables or rows.
Use checks appropriate to your database and application. A success message alone does not prove that every statement in a multi-table file was applied.
Common follow-up questions
Can I simply split the backup into separate files?
Only if you understand the file’s structure and dependencies. Schema statements, foreign-key relationships, and insert order can matter. Prefer a documented export or restore option that produces files for the intended import workflow.
Does this prove the application has a bug?
Not by itself. A mismatch between a table-level import control and a database-wide backup can explain a failure without establishing a software defect. If documentation says the feature should accept that exact kind of multi-table SQL file, collect a minimal non-sensitive example and report the application version, database type, steps, and error to the project maintainers.
References
- dbx issue #13158
- Research reference supplied with the topic — use the application and database vendors’ current documentation to verify version-specific import behaviour.
Dont SPAM