If you've got a lot of old data, you could partition the db so that new data was separate from old data. That could reduce the new partition size...

OFF-TOPIC:

Wow, that's a STUNNINGLY HUGE!!!! change from your responses here:

Be prepared for some effort: format files are a BEAR to get working, esp. the first time you try to use them.

The good thing is, once you get the format...

How does the code "know" which row(s) is(are) the "exception" rows...

Note that you can still defragment the index "live", you just can't fully rebuild it.

I don't see any restrictions like that in MS docs on online index rebuilds. So that is an odd error.

It sounds like it means that if a text column is in the table at all, you can't rebuild online. Will reseach more to confirm.

Which version of SQL?

I would use a temp table for this.

You also need to get away from the dynamic SQL

INSERT INTO #table --or @table may work

EXEC sp_replmonitorhelpsubscription NULL,NULL,NULL,0,0,0,NULL,0

It's safest to always add EXEC before stored proc names.

Because only the first statement in a batch has the EXEC "implied".

CAST the result to decimal(nn, 2).

For example, something like this:

SELECT

'DataSize' =

CASE WHEN DataSize >= 1024

...

select a.*, b.*

from TableA a

inner join (

select clientid, MAX(tbid) AS tbid

from tableB

group by clientid

) AS bMax...

I have tested DENY, even up to db_owner, and it works (interesting that it worked even for db_owner).

But my extensive testing was under SQL 2000. Naturally you'll want to...

There is a separate DENY command:

DENY DELETE ON <tablename> TO <user/role>

I think you can even specify multiple tablenames and/or users and roles in the same command.

[EDIT: You cannot specify multiple...

Yes, you need a trigger on every table.

You could try DENYing them DELETE (which is stronger than just not GRANTing them permission) as a good first step. But that's...

Are you talking about row deletion or table deletion (DROP)?