Ye Olde GUI Display/sychronization Problem...

I feel like the answer to this should be blinding obvious. I also
feel like it's probably an exercise in an undergraduate database
design course. I'm off to google for an answer, but I figure I'd
throw it out here to see if there's a quick and dirty solution.

I have in my database a table of every position we have here called
Holdings. It would be equivalent to an Inventory table in every
basic design course.

There are many users who could update that table, and also many users
whose display programs wish to have correct values. Here's what
I currently do:

There's a timestamp column in that file. My display apps keep track
of what the max timestamp value they've seen is. Every time they
want to do a sweep of the database, they go and "get everything
that's newer than timestamp X", update their quantities, and display.

Now, the procedure "get everything newer than timestamp X" is where
my question lies.....

It requires (of course) a scan of the entire Holdings table, since
having an index on a timestamp field would be (I think) suicidal.
There's got to be a better way to do that.

I've played around with another solution, which is to have a trigger
on Holdings for insert/update, and in that trigger, I save into
another table the PK of the Holdings which change. That "updated"
table also has an identity field, which is the PK of "updated".

Then, instead of keeping track of the max timestamp and scanning
the Holdings table, I keep track of the max identity in "updated",
and just grab the new rows from there, which are usually only a few
(and are easy to find using the PK clustered index), and then grab
individual rows from Holdings using the stored PK.

As I said in the intro, I feel this should be a completely solved
problem. I have a "correct" solution, but I'm just wondering what
the "correct, and most efficient" solution is.

Thanks,

Eric.