Part 1: db trigger.
This is the key part that will make this solution possible/simple/robust. You will need to create a db trigger that writes to another table (tblEmployeeChanges) each time the employee table has an update or insert. So, if in a particular minute their were 5 changes to the employee table, tblEmployeeChanges would have new 5 records, kindof like this:
EmployeeChangeID ChangeType EmployeeID ChangeTime
1643 Insert 434243 2010-07-23 09:14:04
1644 Update 345345 2010-07-23 09:14:07
1645 Insert 345347 2010-07-23 09:14:21
1646 Update 345438 2010-07-23 09:14:39
1647 Update 435634 2010-07-23 09:14:41
You monitoring web page would then check this table every couple seconds, or however often you wish (when the user hits the "refresh" button maybe), your web page will get this data and show it.
This table might get really big, but would remain pretty efficient with good indexes. You could easily purge the "old data" now and then. You would have the clustered index on EmployeeChangeID or ChangeTime, so constant additions should not be, and querying should not be a big problem.
Part 2: simple web REST service
Make an .asmx page or simple wcf service that takes an EmployeeChangeID, and sends down information for each tblEmployeeChanges record that has an EmployeeChangeID greater than that record.
Part 3: repeating Ajax call** from your monitoring page.
Every, say, 2 seconds, your web page page sends the last EmployeeChangeID that the page knows about. If there are any new rows, your callback function adds them to the display (for the human to see), does a beep or something, and writes the ID of the last change record in the list to a javascript variable or hidden input, to use in the next ajax call (2 seconds later).
Example:
So, at 9:14:38 your page asks for all changes since change 1645, and gets back nothing. Then at 9:14:40, (for change 1646); your page shows that data. Then at 9:14:42 your pages asks for every change after 1646, get's back nothing, etc.
Note on trigger as key to solution:
I don't particularly like triggers, and sometimes go for months without using them. In this case though, it's necessary. Note if you really need to keep track of changes in your system, it's better to have an architecture where every change is kept track of for all values, and each property of each employee is kept in a key value pair table where the latest value is considered the "active" value. This architecture has advantages and disadvantages, and might not be right for you. But if the architecture considers tracking changes to be an afterthought, then tracking changes will have to be handled inelegantly, as an afterthought, with tools like db triggers.