One of my co-workers says about tracking, “One of the big selling points to [Blackboard] Vista is the wealth of tracking data for auditing, grade challenges, and catching cheaters.” Certainly, Reports and Tracking in Blackboard’s Vista 3 is one of the more favorite tools. So making sure the data gets there is critically important.

The tracking data is not immediately written to the database. Instead, its staged on each node and applied to the database on the schedule provided by the UI’s System Administrator role. The schedule can be hourly or daily. We normally have these set to upload daily at 5am which is a slow part of the day. Though, going into splitting our data sets, we had temporarily set them to hourly to ensure the data would be uploaded. Coming out the split, we lost 3 nodes in 3 hours for the first day of classes due to Java issues. Going back to daily upload of the tracking data brought down the rate to about 2-3 nodes a day. Much better!

This data is staged in the form of files on each node. In the domain directory, locate the tracking directory. In it should be files with the date and hour and hour in the name. Each is rolled at the top of the hour. A file called .active-log contains the name of the file being written to and which the node not to upload the data. The data in these files is a little difficult to interpret. However, you can get the timestamp (Java epoch), learning context id, node, role, action, location, and person id in these logs. Working against the reporting interface or tracking data in the database would yield better results as this information is matched against more useful information like the WebCT ID, names, etc.

So, its possible for these files not to get written to the database for one reason or another. One error causes the rejection of the whole file (not just the offending entry). However, attempting to process the same file again does not result in duplicate entries. A short list of problems:

• Database can only accept entries of a certain length.
• Improper use of doublequotes.
• Special characters.
• Sudden node failure.

Database can only accept entries of a certain length. When an event’s length is too long, the database encounters an error and cannot place the entry into the tracking data. Problems is Vista 3’s SP7 caused the problem length to drop to about 590 characters. An update in hotfix 2 increased the event length to 1151.

Improper use of doublequotes. Designers using doublequotes in object names (even properly paired) cause issues. Its possible a hotfix intercepts these as I have not seen a case of this in a really long time.

Special characters. The usual special characters work fine. So your amperstands and colons are fine. Its the  which bother me. Monday, Amy got a report a tracking file had not uploaded. It had one event with a length of 1154 which failed (lines of 1151 length did not have an error). The 1154 length one had a text block that looked like “   ” but when I copy that text locally to Windows, it looks like “”. I think the extra spaces bumped the length from 1151 (just under the fail point) to 1154 (just over) and caused the error.

Sudden node failure. As well as we manage things, unexpected problems happen. We had once incident where we lost 6 nodes at once. One of the aftermaths of that even was a tracking file would not get written to the database for two of the six. It turns out an error was written to the end of the current tracking file at the time. Once the error was removed, the files were processed correctly.

The last two always make me think, “Weird.”