Database Loader Versus Record Import
The Database Loader Versus Record Import table compares difference between the database loader and record import.
| Database Loader | Record Import |
|---|---|
| No Workflow | Workflow based record import. |
| No approval | Records approval option can be added as part of workflow. (The out-of-box workflow supports approval.) |
| No validations | Validations can be added and performed as part of workflow. |
| No record history created | Record history will be created and maintained correctly. |
| No named version created | A Named version will be created and can be used as a search filter. |
| Records will be directly confirmed, no intermediate record state. | Intermediate record states are supported and can be created as part of workflow. |
| Does not support multiple data source based input maps. Only a single file based data source is supported. | No such limitation on data source. |
| Does not support usage of database functions or source expressions in an input map mapping. | Supports database functions or source expressions. |
| Does not support explicit relationships (contains field parsing and processing). | Supports for explicit relationships. |
| Does not support data merging, new version of a record overwrites the older version. | Supports data merging based on configuration. |
| Does not support issuing of change notifications. | |
| Does not support indexing of data in text index (TIBCO Patterns) | |
| Does not support importing more than one child appearing in different rows. | |
| Does not support file type attribute. | Supports all types of attributes. |
| Records already pending for approval will be skipped from processing. | Supports processing of records, which are already pending for approval. Record versions already in workflow are normally floated. |
| Multiple Database Loaders cannot run simultaneously. They will be executed sequentially even though two Database Loaders do not have a common entity. | Multiple imports can run parallel, provided there is no common entity involved in import. |
|
Does not support automatic rollback, incase of error or failure, you need to execute the rollback script manually. |
All types of error handling are supported. |
| No failover support | Supports failover |
| Multivalue attributes are supported with only specific data source format and mapping.
For each value of each multivalue attribute, data source should have an independent column, and an input map should map all those by cloning the attributes. Example - Suppose COLOR is a multivalue attribute and you want to import a record with the COLOR value as RED, BLUE, and GREEN. Your datasource should have three columns for COLOR as follows: Id, Ext, Color1, Color2, Color3 A1,A1,RED,BLUE,GREEN An inputmap should be created to map Color1, Color2, and Color3 to the attribute COLOR. |
Does not have a limitation on the datasource for multivalue attributes. Multivalue attribute values can be defined as different columns, or they can be in a single column with value parts text qualified and delimited internally.
Example - Id, Ext, Color1, Color2, Color3 A1,A1,RED,BLUE,GREEN Inputmap should be created to map Color1, Color2, and Color3 to the attribute COLOR OR Assume the text qualifier is a quotation mark (") as follows: Id, Ext, Color A1,A1,"RED,BLUE,GREEN" An inputmap should be created to map all Colors to the attribute COLOR. |