• Good point... but you have to know what the Recovery Model is set to.  If it's set to FULL, even SELECT INTO is logged.  Again, don't take my word for it... here's a snippet from Books OnLine on the subject of "Recovery Models, Full Recovery"...

    Full Recovery

    The Full Recovery model uses database backups and transaction log backups to provide complete protection against media failure. If one or more data files is damaged, media recovery can restore all committed transactions. In-process transactions are rolled back.
    Full Recovery provides the ability to recover the database to the point of failure or to a specific point in time. To guarantee this degree of recoverability, all operations, including bulk operations such as SELECT INTO, CREATE INDEX, and bulk loading data, are fully logged.

    In SQL Server 2000, you can temporarily change the recovery model to "BULK LOGGED".  In both SQL Server 2000 and 7.x, you can temporarily change the SELECT INTO/BULKCOPY database option using sp_DBOption... in fact, in 6.5 and 7.x, you must enable this setting for SELECT INTO to even work... again, don't take my word for it... here's a snippet from Microsoft and the URL where it came from...

    In releases before SQL Server 2000, creating a permanent table with SELECT INTO is allowed only if select into/bulkcopy is set. In SQL Server 2000 and later, the select into/bulkcopy database option no longer affects whether you can create a permanent table by using SELECT INTO.

    http://msdn2.microsoft.com/en-us/library/ms188029.aspx

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)