Return to Answer

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. And any non-clustered indexes are rebuilt with the new clustered index key as the row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level rows of the clustered index are left in-place and they become the new heap. Nonclustered indexes are still rebuilt as the row locator switches from the CI key to the rowid (file:page:slot).

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. Any non-clustered indexes are rebuilt with the new clustered index key as the row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level pages of the clustered index are left in-place and they become the new heap. Nonclustered indexes are still rebuilt as the row locator switches from the CI key to the rowid (file:page:slot).

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. And any non-clustered indexes are rebuilt with the new clustered index key as the row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level rows of the clustered index are left in-place and they become the new heap.

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. And any non-clustered indexes are rebuilt with the new clustered index key as the row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level rows of the clustered index are left in-place and they become the new heap. Nonclustered indexes are still rebuilt as the row locator switches from the CI key to the rowid (file:page:slot).

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. And any non-clustered indexes are rebuilt with the new clustered index key row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level rows of the clustered index are left in-place and they become the new heap.

Yes, when you create a clustered index on a heap the rows are all sorted moved to the new clustered index. And any non-clustered indexes are rebuilt with the new clustered index key as the row locator.

It's the same table, though, so triggers, constraints, etc don't have to change.

The reverse is not true, however. When you drop a clustered index on a table, the leaf-level rows of the clustered index are left in-place and they become the new heap.