I think you can configure replication to not replicate the deletes when you purge the old data from the source server. (It's been I while since I used it)

What is your question ?

CirquedeSQLeil (1/22/2010)

---

It might be trying to do a sort operation while you do that. What is your clustered index on?

it does seem pretty big - better than it was,...

Not again ??!! 😀

With DTS, wouldn't you have to delete the previously migrated data & reload ?

I would think replication would be easier since it can push just data changes since the last...

Perhaps the tables are small, so although they are fragmented, they are too small to defragment.

select datepart(hour, getdate()) -- Get just the hour ... in "military" hours

Look into the DATEPART function. That may be what you need.

I re-ran it without the index, but the log file was still 23 Gig .... seems awfully big compared to my 1 Gig temp table that was loaded.

Using backup history assumes you don't delete backup history as some people do. It was pointed out in another thread a little while back that having large history files in...

I found some old code I used to get rid of CR_LF in the data.

update MyTable

set cm.csm_description = replace(replace(cm.csm_description, char(13), ''), char(10), '')

where charindex(char(10), cm.csm_description) > 0 ...

I was suggesting using the backup information to get growth trends from the past to help in planning for the future. They will not be accurate for point in time...

In that case, read up on the 2 upgrade methods, then come back if you have questions. You will probably see mention of the Upgrade advisor. It's a useful tool...

murthykalyani (1/22/2010)

---

I don't this so this will give you good results. consider the case...

jeffmc123452003 (1/22/2010)

---

not to sound stupid or anything but can you direct me to a few links for the inplace upgrade? I just made a vmware image of the server...