MF_KeyedComputerInUse

<None>

The data here is actually just a repackaged version of what's in MF_KeyedComputerEvent.

Unlike MF_KeyedComputerEvent, which records all logon, logoff, server up, and server down events (and maybe more, depending on what filter(s) are defined), this table records only 'session' events, in particular, logons/logoffs (other events are used only to infer when a session has ended, due to a crash, power outage, etc.).

The logon events, though, are regrained to ten-minute increments. If a computer is in use during one of those increments, a row is added to this table. Omits an entire session if it lasts more than a day, because the data is no good. Probably the computer is sleeping most of htat time. Obviously throwing out long sessions doesn't make sense if we're measuring usage on staff or faculty desktops, but in fact we're looking specifically at lab/shared machines here (or ones marked as such in WHD), so throwing out long sessions is completely warranted.

Just to make the point really clear: THIS VIEW DOES NOT PROVIDE GOOD MODELING OF NON-LAB/SHARED MACHINE USAGE. Among other things, it throws out long-running sessions, because if we kept those, we'd end up with very skewed stats for machines where people log in, then stay logged in, often for months at a time. This produces very long-running sessions and gives the impression of a heavily used machine (because someone is always logged in). This view is not intended for such machines, but rather for lab and other shared machines intended for short-term use (less than a day at a time).

To be used analytically, the data here must be joined to a coverage table that has all times available to it. The view VMF_KeyedComputersInUse does this, and for that reason is extremely slow. VMF_KeyedComputersInUse serves as fodder for multidimensional cubes, and is documented elsewhere (ViewsLabUsage package).

This table is joined to buildings, rooms, users, and general asset data, but not reliably. The process of linking a row here to an asset involves 1) tying the row to a computer inKSComputers, then 2) tying the MAC address (or, alternatively, part of the key) to an MD_IssueTrackingAsset, and from there to a MD_CarletonDepartment, MD_TicketTrackingUser, MD_Employee, MD_Building, and MD_Room.

Please note that as of June 2012, the left outer joins do not work right when we query K2 using 7.x ODBC drivers, and it is not possible (it appears) to limit rows by date, at least for our 6.x database.

For more information on the K2 schema, see:

http://www.sassafras.com/hrl/7.0/tables.html