Just ran into a new terrible design choice again on the MAPIMPORTFDO command.
We have defined the import settings earlier and saved this configuration into an import profile (ipf file). This has only a limited subset of the feature classes (tables) from the schema selected (to be imported).
Great to be able to store the settings of the mappings etc for recurrent work and jobs.
In the mean while other tables were added to the schema.
When running the MAPIMPORTFDO again, these newer tables are obviously included in the list of the available feature classes/tables. As default apparently all tables are always selected.
As we do not need those tables to be imported, we load the import profile again from the ipf file.
What turns out: you have to check that list again as the MAPIMPORTFDO tool will add by default those new tables in the subset of the feature classes to be imported from the saved settings ipf file.
This happens even while we first deselected all tables prior of loading the ipf file.
The result is that all tables from the IPF file are selected in combination of all the new tables that were added to the schema since the last save of the ipf file.
How stupid is that?
This means that every time this import profile is being applied the user has to check if no other new tables were created in the schema and unselect them explicitly from the list. This is not only annoying, it is also contra-productive in terms of reusing previously stored settings.
Also, the user that need to load the profile, is not always up to date if there are feature tables added to a schema, so he must be very secure in his work to avoid importing unwanted tables, while the ipf file should be the only reference for selecting the tables for import.
Also in an Oracle environment it happens that a lot of tables exist and are added to a schema.
Bad design choice if you ask me.
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register