It may be in the wording I used, but if you have a clustered index and insert new rows, it is very possible (especially in the situation being discussed for the Financials table) that the Row or Page could change for an existing row. Because non-clustered indexes contain pointers to Page/Row, these then have to be updated for every record that was "shifted". I believe SQL Server does do this on every insert. It may not "rebuild" the indexd but it does have to resynch the index nodes.

>> The reason is that each time you add or update a record with a clustered index, the entire indexing structure must be rebuilt. It is better to drop the clustered index, make all the updates you need to and then rebuild the indexes once.
>
>Maybe I'm missing something here but SQL Server does not completely rebuild any index everytime a row is inserted, updated, or removed. When a row is inserted, SQL Server finds the proper position of the new key in all the indexes and inserts it. If there's not enough room on the page, the page is split and some of the keys are distributed to the new page. When a row is updated, any affected indexes are updated. If the index key was changed, the key is moved to it's new position. When a row is removed, all the indexes are updated and the applicable keys are removed.
>
>As far as I know, the only time that an index is completely rebuilt is during maintainence activities, or when a Clustered index is dropped and/or created and non-clustered indexes already exist.
>
>-Mike