No... that will just delete the first n rows, regardless of the path.

DELETE TOP...

... or if it's homework, you need to do a bit more studying.:-D

There are so many things wrong with this approach, a lot of which you've already recognized.

You've completely blown away any transactional integrity. How can you guarantee that the job succeeds...

I appreciate the difficulty here, but I wouldn't...

Err, Jack, isn't

SELECT A.*

FROM A INNER...

Lynn Pettis (7/1/2009)

---

Actually, I keep checking my calendar and I can't find ASAP. I can find Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday; but no ASAP. ...

Restoring with "STANDBY" is always going to be slower than "NORECOVERY" because SQL Server has to leave the database transactionally consistent in between restores (hence the .tuf file which contains...

Before you think about performance, those are logically different queries anyway.

If you have 2 rows in B for the same ID, the first query will return 2 rows, but the...

At least thats smaller than the 86839MB you originally had.;-)

You said this in the original post

Are we...

Is the log still growing?

I was suggesting that the log had PREVIOUSLY been in Full recovery (which caused it to grow).

Although it is now in Simple, that in itself will...

DNA (6/30/2009)

---

Also, it does not stop you using features that are above the compatibility level you have set - so if you were to set the level to 8 then...

I suspect that you had the database in "Full" recovery mode at some point, without a maintenance plan to back up the transaction log, so it will have continued to...

Probably a long shot, but the only time I've seen anything like this before was when a heavily used stored procedure was rewritten to use temporary tables.

The stored procedure was...

You're welcome:-)

If the FK column isn't the first column of the composite index, then SQL Server will revert to clustered index or table scans, which is what you are getting.

I wouldn't...