ive used this in the past; it's a cursor, and resource intensive; it takes a couple of minutes to run on my 100meg database with 100's of procs and 1400+tables:

sample...

translated via Google: basically fill out my survey and maybe win an Ipod:

also psexec is a command line program from sysinternals.com...is that installed in the path on the server?

just one more thing to double check.

take a look at this thread from a couple of years ago...someone adapted the hex scripts to do this:

I see that that takes care of %20 kind of stuff for...

for both SQL's, you'll want to view the estimated execution plans. they will be different, becuase the second sql is returning data from the other table

Is there an index on...

just a bit of clarification:

the program Purge.exe exists on the SQl server itself, right? not locally?

here's a typical example of what i might do: i put file contents in a...

i think if you use xp_cmdshell 'C:\purge.exe 7' it will work; I know I call executables with command line arguments like this all the tiem.

this is how i typically do a big group of transactions;

note that i use SET XACT_ABORT ON, which means if any error gets raised, it rollsback the transaction automatically, so...

and based off of Mohammed's example, here's the limit after 20 example:

drop table #test

Create table #test (

publicationdate datetime default getdate(),

NoOfDays as CASE WHEN datediff(dd, publicationdate, getdate()) < 20 THEN...

i have this snippet where i was looking for the defined row size for each table:

this might help as well:

create table ##tmp (TableName varchar(40),DefinedRowSize int)

sp_msforeachtable 'INSERT INTO ##TMP Select...

very true; don't abreviate anything; readability is critical.

 I have developers here who never heard of the *= join operator; ....someone might look at that, think it's a syntax error, then...

the model database, or any database for that matter, does not contain within itself it's own storage location...that is kept in master....the model database is used for the default schema...

just a follow up; i got the estimated execution plans for a join against two of my big tables using the commands below, and they had both identical estimated execution...

*= got deprecated in sql2005, so i'd suggest switching over to the standard format; it's more readable, and is also ANSI compliant, so you can use the same SQl statement...

i think in this case, you would want to raise an error if the value being tested('xxx') was not really numeric; there was another thread on this same subject, and...