"What I did on my spring break" or "Database and tracking"

I'm going to start with what I now know that I didn't know before. This is hard won knowledge bought with sweat, tears, hand waving, loud conversation with my wonderwoman colleague, Tracya Brown (DBA/Developer) and many back and forth exchanges around the what do we do now question.

  • The webct.rpt_tracking view references 4 underlying tables where tracking information on an individual's activity is kept.
  • When an individual's account is deleted from Bb Vista (8.0 in this case), by accident or, for many institutions, because they recycle userIDS (not us and you should NOT be doing this), the individual's person record (webct.person) ID value is written to the column "DeleteStatus" where it remains and where, by constraint of some type, it can not be easily returned to its former null state. This has stupid consequences.
  • When the accidentally deleted account is recreated by whatever means, it is not TRULY recreated as one might suppose based on the shared key with ones SIS. Rather, a new Bb Vista person record is created.
  • Or, when one of your Administrative Offices creates duplicate userIDs for the same admitted student and the student is advised 'use this one' and then, 'use that one' – the student's work as recorded in Bb Vista can most likely NEVER be merged into a single account on God's green earth. (Oh please Sherryl Meads Now of Blackboard..say this isn't so by the end of the day!)
  • If you were to restore a backed up section containing the deleted student, you would also create a NEW person account for that student, which contains only the learning artifacts from that section.
  • If you were to restore a backed up section as above but check to include the restoration of tracking data? What happens then? You'd think… But no, that tracking data becomes owned by the new user created during the section restore. This too has stupid consequences in the enterprise realms of Auditing and data warehousing and reporting on usage. Yes, it means duplicate tracking events. One set owned by original deleted user and one set owned by new imported user.
  • A bit of good news… restoring the 2nd …3rd …and subsequent sections containing selfsame user do not create even more person accounts. Since the 1st section restore created the new user with a DeleteStatus of null, all subsequent restores aggregate their tracking data under this account… but of course, in aggregate they are duplicating what is already contained under the deleted user in your tracking data.
  • Powersight reporting  views as given to us by Blackboard contain, for better or worse, events associated with deleted users. Not bad if you never recreate the user again. But bloating the report if that user has been recreated. (I guess this means the PowerSight views were built to support the bad practice of recycling/reusing user logins but it should be more likely that the userID still refers to the same person and that person needs to have one seamless tracking history).
  • From the Instructor's point of view, restoring a section with no tracking data means nothing the student has done up to this point in the semester is viewable to the Instructor.
  • From the Admin's point of view (or DBA's), restoring a section WITH tracking data means duplicate tracking data if said section contains any users which no longer exist on the system.