Driving Sets for Import Tasks

Previous Next

See Also

When several files are imported within a single import task, there will be an external set for each file. In this case, you must specify which external set is the driving set. Each import task has exactly one driving set.

For example, suppose that the Travel Agency is in the middle of a large conversion project, in which files from different systems have to be converted into a single database. They have one file which contains information on scheduled tours, and another which contains reservation data. Because a scheduled tour may have more than one reservation, this file will be chosen as the driving set.

The files that you choose to be "non-driving" are read into temporary tables in one go. The file that you choose to be "driving" is read into a temporary table in memory or in the database, one record at a time. The validity of the resulting data is checked before the data (in this case the tours and their reservations) is inserted into the database.

The driving and non-driving sets use the external set as a table. See: "Storing External Set Data in Tables" Storing External Set Data in Tables.

When you execute an import task using a driving set, the USoft Batch Runner:

· Makes sets available as tables.

 

· If necessary, existing records in these database tables are deleted.

 

· Reads the non-driving sets into temporary tables in one go.

 

· As long as there are records in the driving import set:
1. Reads a record and inserts it into the driving set.
2. Executes the import SQL statements defined for the import task.
3. Deletes the driving set record.
4. Commits the data if the import task has row-level commit.

If the commit fails, rolls back the transaction and writes the record in the error file.

· Makes sets unavailable as tables.

NOTE:

When running an import task, it is possible to delete the record in the driving set via a DELETE statement . This rejects the record being imported. This way, you can filter the records to be imported.

You should take care with task-level commit import tasks since the DELETE statement causes a rollback for the complete task. It is therefore only useful for record-level commit import tasks.