I've got a table in SQL Server full of data that is a working DB of data collection reports. This table only stores the current state (meaning it doesn't keep historic anything).

There are a few key metrics that I'd like to begin tracking over time from this table. Most notably the table has a user's name, their assignments (one row for each), status values (in progress, scheduled, etc.) and last activity date.

Because the table itself doesn't have any history information, I'm looking for the best way to sample the data on some periodic basis recording the current state values and timestamping it. Once this is done, I'll be able to ask questions via reporting like "How many reports was Joe working on on tuesday and what were their statuses?"

What would be the best way to do this, short of creating a SQL Server table to house the information, writing scripts to do the collection and a report/query interface for all of this?

My google-fu is usually really strong but the general concepts are colliding way too firmly with proper names of things that are completely unrelated, thus I can't find any good info out there.

Anyone got experience with such a process? What can you tell me to get me on the right direction?

Edit: I do not currently collect the aggregate data, nor do I currently have a place to store it, though that could be as simple as a SQL Server table. I'm not going to be able to spend as much time as I'd like supporting this reporting capability, so I was hoping for some type of a packaged solution that some admins can maintain with minimal development efforts.

  • It sounds strange to me to want to collect aggregate data from the local dataset, but not have a place (such as a table) to store it. Perhaps you could edit your question and explain just a bit more.
    – RLF
    Commented Nov 12, 2015 at 15:43
  • @RLF I've added a bit more detail.
    – Tony Baker
    Commented Nov 12, 2015 at 16:01

1 Answer 1


You can create triggers that are fired upon insert/delete/update in the table to write the data you need in a separate history table. You can then later query this table to create your reports. No need to change the application that is now responsible for maintaining the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.