Databases - IBDataPump Analysis

This is a partial analysis related to importing an MS Access database into Firebird using the IBDataPump.

In this analysis, I have added spaces and made other editorial changes to improve readability.

Basic Table Conversion

This worked pretty good - no complaints.


Indices are a general problem In MS Access, the Batch_Preparation_tbl table had only 2 indices Most MS Access tables contain a PrimaryKey index ... mainly because Access prompts you to create one each time you create a table. As a result, you will get multiple warnings when you run IBDataPump. When these are too long (more than 31 characters), you will need to manually shorten them. (I provide a program to semiautomate this task.) This example is after running Shorten_SQL_Names.exe and manually removing the extra comment delimiters. I see no reason for the Batches_tblBatch_Preparation_tbl index.
(Perhaps that is just my ignorance showing.)

Both Batch_ID and Performed_By are associated with entries in other tables ... but those associations are not included in the generated sql file.

Referential integrity is defined between Batches_tbl and Batch_Preparation_tbl ... perhaps that produced the Batches_tblBatch_Preparation_tbl index.


The "ID" field is defined in MS Access as autoincrement - thus the datapump automatically produced a generator.

The current maximum ID value was 4 - so the generator was properly initialized.

Notice that the trigger is not marked as active ... this allows the datapump to copy existing records to the table without calling this function. However, because of the null test, there would not be a big problem.

Author: Robert Clemenzi -
URL: http:// / user / clemenzi / technical / Databases / Firebird / IBDataPump_Analysis.html