Just a word of caution here... the script is fine and the reason for disabling indexes prior to rebuilds or imports is great but be very aware that if you disable an index that an FK is pointing to, it will disable that FK and you'll need to rebuild the FK. Here's the skinny from BOL on the subject...
When disabling a unique index, the PRIMARY KEY or UNIQUE constraint and all FOREIGN KEY constraints that reference the indexed columns from other tables are also disabled. When disabling a clustered index, all incoming and outgoing FOREIGN KEY constraints on the underlying table are also disabled. The constraint names are listed in a warning message when the index is disabled. After rebuilding the index, all constraints must be manually enabled by using the ALTER TABLE CHECK CONSTRAINT statement.
To be sure Jonathon mentioned that this would be used "when inserting data into a staging table on a data warehouse", which also means that there are probably no Foreign Keys pointing at the table in question. I just want to make sure that people don't do such a thing to real tables during inserts or index maintenance without knowing that there are other serious ramifications to be had.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)