Dropping a clustered index

If I have a large table (130 GB, 330+ million records) on which there is only one index and it is clustered, should dropping that clustered index be a "fast" operation or would SQL have to do a lot of work behind the scenes that could take some time (hours)?
Thanks,
Aaron

Thanks. I'm on SQL Server 2000 Enterprise Edition, but I'm betting this is also true for it. I'd like to still hear from others if they have experience with this or anything to add to it.
Here's an excerpt from the SQL 2005 BOL entry referred to by FrankKalis:

"In the logical phase, the existing allocation units used by the table or index are marked for deallocation and locked until the transaction commits. With a clustered index that is dropped, the data rows are copied and then moved to new allocation units created to the store either a rebuilt clustered index, or a heap. (In the case of an index rebuild, the data rows are sorted also.) When there is a rollback, only this logical phase needs to be rolled back. "

[quote user="asentell"]If I have a large table (130 GB, 330+ million records) on which there is only one index and it is clustered, should dropping that clustered index be a "fast" operation or would SQL have to do a lot of work behind the scenes that could take some time (hours)?[/quote]
I would think so..What is it that you are trying to do eventually?

Also remember it can have side-effects such as query plans getting screwed up for not finding the index...

We have two databases: Online and Archive. Online is 6 weeks worth of data, and Archive is a full history of data. Once each week we migrate data from Online to Archive using a DTS package. One unfortunate characteristic of these databases is that GUID columns are everywhere, and there are clustered indexes created on many of them. My idea was to drop the clustered indexes in the Archive database before running the migration job, thereby speeding up inserts, and rebuild the clustered indexes afterwards. This would also allow me to compress the indexes (fillfactor = 100) and eliminate the need for a separate reindex job for these tables at some other time.
With an upcoming upgrade to SQL 2005 I hope to utilize partitioning and SSIS to improve this process even more.