I took a quick look Pharos' Batch Load Technical Information document and it doesn't appear to be the case. It reads like any "blank" fields that are read will result in the current data in the Pharos User table being overwritten with the empty field.
What we ended up doing is creating a second database on the MS SQL server that hosts the Pharos database. The new database serves as an ODBC conduit to our card server (e.g. Blackboard Transact). We went the route of creating a second database so we didn't have to mess with the schema of the Pharos database which makes Pharos software updates simpler. We then created a SQL Server Agent job with four steps in it.
- Check to see if the MS SQL server can reach the Card Server db (the two db's are on physically separate boxes), if so continue, if not fail and send warning
- Check to see if the temp "processing" table in the conduit database exists, if so then drop the temp table.
- Upload the Card ID information from the Card Server to the temp table (it's created as part of the process), and do some basic processing.
- Update the Pharos Users table "card id" field based on matching information (i.e. University ID) that is common in both the Pharos database User table and conduit database Card ID processing table.
This process then automatically (scheduled as a nightly job) updates the "Card ID" field in the Pharos Users table based on information in the Card ID server. This does assume that that the individual's University ID is already loaded into the Pharos Users table (we use the "Custom Field 1" to store this data). Our nightly batch user account provisioning process uses the Pharos Userload tool to create/update the accounts with this and other information before the Card ID update process runs.
The other nice benefit is between these provisioning steps and somewhat intelligent login/billing scripts the Pharos "print release" process can fairly dynamically handle use-cases where a patron's card ID changes between one nightly batch run and the next (e.g. they lost their university ID and was provided with a new one that has a new "issue code").
Hope this helps,
2 of 2 people found this helpful
Fields without values in them in the csv file will be skipped when updating a user, so will not cause an existing value to be deleted when updating users. Your sample is correct - only those fields with values in them will be updated. It looks like this needs to be clarified in the documentation.
That's good to know. I guess the follow up question is if fields without values in a CSV file are skipped, how would one use a CSV file to intentionally replace existing values with a blank value? I can think of several use-cases where this would be beneficial.
Thanks Katherine, that worked perfectly. We're going to use this format:
This will get us the Mag Track we need and Email Address.