Overview
When a user imports a spreadsheet into DBM, the system executes a series of layered validation checks to ensure that the data is structurally correct, relationally valid, and safe to process. These validations are applied at different stages of the import workflow and are designed to prevent invalid, incomplete, or corrupt data from being loaded into the database.
This page provides a consolidated view of the key generic validations that are commonly enforced during the import process. Please note that, in addition to these, table-specific and field-specific validations may also apply depending on the schema and configuration.
Validation Rules and Enforcement Stages
1. Table Name Validation (Cell A1)
When enforced: Always
Validation stage: Sheet header read
The value in Cell A1 is mandatory and is used to identify the target database table for the import. During the sheet header read phase, DBM validates that:
A table name is provided
The table exists in DBM
The user has permission to access and import data into the table
If this validation fails, the import is blocked immediately.
2. Primary Key Column Validation
When enforced: Always
Validation stage: Prepare phase
DBM validates that all primary key columns defined for the target table are present in the spreadsheet. This ensures that each record can be uniquely identified and processed correctly.
If any required primary key column is missing, the import cannot proceed.
3. Foreign Key Column Validation
When enforced: If the table has a parent relationship
Validation stage: Prepare phase
For tables that have parent–child relationships, DBM checks that the corresponding foreign key columns are included in the spreadsheet. This validation ensures that the imported data can be correctly linked to its parent records.
Missing or invalid foreign key columns will cause the import to fail.
4. Cross-Link Table Primary Key Validation
When enforced: For cross-link tables
Validation stage: Prepare phase
Cross-link tables rely on multiple primary keys to establish relationships between entities. DBM validates that all required primary key columns for the cross-link table are present in the spreadsheet.
If any required key is missing, the relationships cannot be established and the import is blocked.
5. NOT NULL Field Validation (Column Presence)
When enforced: When importing new records
Validation stage: After field importers are created
When new records are being inserted, DBM checks that all columns marked as NOT NULL in the table schema exist in the spreadsheet. This validation focuses on column availability rather than values.
If a required NOT NULL column is missing, the import fails.
6. NOT NULL Field Validation (Value Presence)
When enforced: Always, for NOT NULL fields
Validation stage: LoadRows phase
During row-level processing, DBM validates that every NOT NULL field contains a value. Empty or null values are not permitted for these fields.
Rows (or batches) containing invalid null values will fail validation.
7. Unique Identifier Validation
When enforced: When uniqueness checks are required
Validation stage: Prepare phase
For fields configured as unique identifiers, DBM validates that incoming data does not violate uniqueness constraints (for example, duplicate identifiers already existing in the system).
If duplicates are detected, the import is blocked or errors are raised accordingly.
8. Field Value Completeness Validation
When enforced: When keywords are used
Validation stage: Prepare phase
When the spreadsheet uses keywords or derived values, DBM validates that the resolved field values are complete and valid before proceeding. This ensures that keyword-based imports do not result in partial or ambiguous data.
Invalid or incomplete values will prevent the import from continuing.
9. Batch Processing Validation
When enforced: Always
Validation stage: Load Rows phase
To maintain performance and data integrity, DBM processes imported data in batches of 32,000 rows at a time. Each batch goes through the same validation and processing steps independently before being committed.
This approach helps prevent system overload and allows controlled handling of errors during large imports.
Summary
These validations work together to ensure that:
Only structurally valid and complete data is imported
Database relationships and constraints are preserved
Large datasets are handled safely and efficiently
Partial or corrupt data loads are prevented
While this page covers the generic validation rules, additional field-specific or table-specific validations may apply depending on the data being imported.