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"...
- 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.
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs