Lynda,

BCP is additive so you shouldn't have to drop indexes. The BCP will not be "fast-bcp" if indexes and constraints are in place, but it should still be pretty fast. The other problem with BCP is that it's non-logged activity which severely impacts recoverability and your DBAs aren't going to like that.

I move lots of data from imports into the backend. I BCP into tables in a staging database and then run an insert into the live database a select from the staging and then truncate the staging table. This works well the the logs on the prod db aren't invalidated.

Another way I use to move rows from one prod table to another is at the office right now I can post that tomorrow.

The other thing you have to be careful of is making sure your batches of records moved/deleted are small enough that you don't fill the transaction logs and that's not a pretty sight either. *bg*

>That's not very practical from a business standpoint. History data is used in separate forms (only one field can be edited for example), used in different reports and has more and different indices. With about 15 years' worth of data to store, we really don't want it in the active transaction tables. We're trying to keep them "lean and mean" for the benefit of everyone, but especially remote users who only have dialup access <g>
>
>I've looked at BCP but it's a bit of a pain to have to drop and rebuild the indices each time. I thought there might be other options.