I think you have the right idea there... an EXECUTE SQL TASK could pretty much take care of the whole shootin' match, so to speak, assuming that the data exists and remains in the same server. I'm just looking at this from the perspective of what happens a few years down the road, when perhaps there are quite a few more records than exist today, or when a window in which this takes place has to shrink significantly. Efficiency today means less work down the road, and that's usually the best thing for any business. Without a lot of specific details about the WHERE for this data in terms of same server vs. different server, it's hard to know exactly what would work best. Usually, it's best to use SSIS to move data between servers or DB instances, and a simple SQL Script set up as a SQL Agent job could be enough to handle data when it's all on the same database server / instance. It will usually perform better as a single script rather than involving any kind of user-written looping mechanism. Does that help explain?