I am facing a conceptual problem that I am having a hard time overcoming. I am hoping the SO folks can help me overcome it with a nudge in the right direction.
I am in the process of doing some ETL work with the source data being very similar and very large. I am loading it into a table that is intended for replication and I only want the most basic of information in this target table.
My source table looks something like this:

I need my target table to reflect it as such:

As you can see I didn’t duplicate the InTransit status where it was duplicated in the source table. The steps I am trying to figure out how to achieve are
- Get any new distinct rows entered since the last time the query ran. (Easy)
- For each TrackingId I need to check if each new status is already the most recent status in the target and if so disregard otherwise go ahead and insert it. Which this means I have to also start at the earliest of the new statuses and go from there. (I have no *(!#in clue how I’ll do this)
- Do this every 15 minutes so that statuses are kept very recent so step #2 must be performant.
My source table could easily consist of 100k+ rows but having the need to run this every 15 minutes requires me to make sure this is very performant thus why I am really trying to avoid cursors.
Right now the only way I can see to do this is using a CLR sproc but I think there may be better ways thus I am hoping you guys can nudge me in the right direction.
I am sure I am probably leaving something out that you may need so please let me know what info you may need and I’ll happily provide.
Thank you in advance!
EDIT:
Ok I wasn’t explicit enough in my question. My source table is going to contain multiple tracking Ids. It may be up to 100k+ rows containing mulitple TrackingId’s and multiple statuses for each trackingId. I have to update the target table as above for each individual tracking Id but my source will be an amalgam of trackingId’s.
Here you go. I’ll let you clean it up and do optimizations. one of the sub queries can go into a view and the messy date comparison can be cleaned up. If you’re using SQL 2008 R2 then use CAST as DATE instead.