How different is the new number? Here at WSU their ID number (not the same as network ID) is embedded into a well known portion of their card data - we then parse the data from a card swipe to recover the ID # and match that with their email. This of course implies that we use a script written for us by the good folks at Pharos.
The process that prevents students from losing their cards is known only to ..., and knowledge of that process is not meant for mere mortals.
They are 16 digit card numbers. the first 7 are the same, and our script captures the last nine as a unique identifier. We have since fixed the problem by changing the script to capture the users Identikey ( a unique number\alpha combo) as the login ID, since it's static. Now they can lose all the cards they want and it doesn't affect the Pharos account matching the user ID with a specific job.
Depending on how your card system is setup the following might work. We use Blackboard (Bb) Transact as our card system and within that system, for cards issues to specific persons, it stores the individual's university ID number. We've setup a multi-step user provisioning process which runs nightly that accounts for the following:
- Update Pharos DB info for existing user's that have a username change (vs. creating a new Pharos ID for the same person).
- Add recently created/updated user accounts with appropriate attributes (email address, etc.)
- Add/update any card ID information to user accounts.
- Sets the offline billing amount.
This above process is achieved via various means (powershell scripts, sql scripts, Pharos userload.exe, etc.). One of the key points is tied to the individuals university ID number which is stored within the Pharos DB in the "Custom1" field. We then use this field as a comparison when needing to automate changes to other values since each value should exist for one and only one record, and is only set/updated via this automated provisioning process. Since the university ID number does not change within the Bb Transact system when a new card is issued it is a relatively trivial process to programmatically update the new card values on a scheduled basis. Within the SQL Server hosting the Pharos DB we have a SQL scheduled task that automatically checks once a day against the Bb Transact system for the current card values and then updates the Pharos DB card field with the current value. Additionally, we're using login/billing scripts that compare against the Custom1 field to make sure the card id field is updated with any new card numbers during the course of the business day in-between the nightly updates in case cards are lost, replaced, and used the same day.
And as Kurt mentioned preventing the loss of cards is a secret not yet ready to be revealed...