Spire UDF Import

Spire UDF Import imports data directly into Spire UDF fields from Excel.

Features include:

  • Use either the Spire API or ODBC to update the Spire database.
  • Make backups of your UDF fields before updating.
  • One-click restore of backups.
  • Run multiple imports consecutively in one batch.
  • Field by field logging of update success/failure with reasons.
  • Single record testing mode.
  • Filter errors and re-import errors after fixes.
  • It is FAST! How fast? Keep reading.

Here is the main configuration Control Panel for Spire UDF Import. Only 3 pieces of information are required to configure each import method, either API, ODBC or both. API updates are slower, but have the advantage of implementing the built-in Spire validation.

Unlimited Import Configuration

The Imports sheet contains a list of all configured import destinations. Although not shown, all Spire UDF destinations are supported. Some are only supported via ODBC. This sheet has a link to the associated source sheet for the actual data.

The source sheet for an import includes unique key information and a column for each UDF field to import. You are not limited to the normal ‘primary’ unique key. Any combinations of key fields that are unique can be used. If the key combination is unique for a given record, it will update. If it is not unique for a given record, that import will not take place.

In this example, the UDF fields are called “value”,”notes”,”lastcontact”, “nextcontact” and “salesstatus”. These names relate directly to how the UDF fields are configured in Spire.

After running the import, the Row Results and the Backup columns have been populated. In this case, the API was used, so the UDF field validation was enforced. One record update was denied, and the reason is shown. Another record indicates that the customer number in the import data does not exist.

A filter can be applied to the Row Results column to show only the errors and they can be fixed.

The incorrect customer number and the invalid ‘nextcontact’ date are corrected. The filter is left in place for the next import, as the import process does not import records that are filtered out. Here is how things look after the second import.

Now that the customer number has been corrected, that record could be validated and was found to also have an error. The final step would be to fix this error and re-run the import. All the records would now be imported and the filter would be showing zero rows.

And the performance? 4,200 customer records with 2 UDF fields per record, while making a backup of all the UDF data before each update took just 25 seconds. The restore was even faster.