alen teplitsky (3/9/2011)

---

if the TRUN CATE TABLE command is logged, why can't you run it on a table that is published for replication?

Steve Jones - SSC Editor (3/9/2011)

---

It's clear to me, and if you think there is some implication that you are restoring to some specific point in time, you are reading something into the question that is not there. The question asks simply if you can restore to a point in time, and you can, based on the transaction log backups. The truncate statement is listed to see if you think this affects your log backup/recovery, which it doesn't.

I'm sure you've read something about this on the Internet, but it's not true.

sknox (3/9/2011)

---

Essentially, TRUN CATE TABLE simply invalidates all of the pages related to the table in one operation with no row-level checking. Since replication acts on row-level processing, a table-level command like this is not allowed. Same reason you can't do it on tables with foreign keys and it won't fire any triggers. Also the same reason it's generally so much faster than DEL ETE

[Sorry for the extraneous spaces -- stupid IPS can't tell the difference between a comment and an attack]

alen teplitsky (3/9/2011)

---

that's why i think this is a bogus question. technically everything in SQL is logged or whatever because the system has to execute it and it has to know what to execute against. but practically this is not a logged operation.

i clicked the SQL Skills link expecting some cool info on how to recover the lost data, but no such luck

wware (3/9/2011)

---

Good question. Please don't hesitate to submit more. I speak for the 62% who read the question as you intended and answered correctly. Our knowledge was reinforced. The folks who answered incorrectly but understood the question as worded really learned something today!