Store the DB object definitions...ie the DDL + SP's....in a version-control application like MS Sourcesafe (or other better products).

Apply a security policy to ensure the objects in the DB can only be...

MAX....

you forgot to put your question in context....ie a link to the original problem you are quoting against....

you're bitching about something....but not giving the full info so that the rest...

some thing on the lines of the followng should get you there....

select * from table b inner join

(select factor, min(date/time) as mindate from table

group by factor) as a on b.factor...

why not 'always create' the extra fields and use the likes of a CASE statement to conditionally fill them with the required data...based on the user profiles....if it turns out...

Averaging is one of the AGGREGATE -type functions.

look up BOL for details.

Select cola, count(colb) , avg(colb) from tablea group by cola

is along the lines of what you want.

note: count(*) NOT...

select columnx, count(*) from tablea

group by columnx

is how you do aggregates.

index_hints....spelling/punctuation might be wrong....but look in BOL for info...or search here for the keywords "with index, hint"

scans....prevent by ensuring columns...

Best Advice: STOP using CURSORS.....the 'relative' performance (with large datasets) compared to SET_BASED PROCESSING is cr*p.

Your best strategy is to segment what you are doing into discrete sets (1 type...

UNLESS you are doing something in the cursor which requires the results of 1 record in the cursor to affect the calculations of the next (or subsequent) record in the...

it is feasible....

either to swop the test server into place of the prod server?

or to cut another server to 'ghost' the test server configuration...with the production name...and just dump the...

your problem was more interesting than my work.....

I can tell you the exec-plans are different....print them out and compare line by line....you'll see they diverge quite fast.

i'd be interested to...

lateral thinking here...

why not simplify the "dateadd(m,-5,getdate()-datepart(d,getdate())+1)-1)" construct to a pre-determined variable....and at least take the inclusion of the formula "dateadd" out of the performance equation.

you can compare test + live setups...using s/w like sqlcompare from redgate.com.....and/or db/ghost....

that will deal with any 'inside sql' differences....other differences could be at disk/network level.

also index hints....might work to force the...

in general caching will affect test run timings...and doing as advised with the dbcc commands will be more accurate....

the advice given was to totallly eliminate it as a factor.

can you...

To remove the data-caching effect of the results of 1 test run influencing another test run....investigate and execute both DBCC DROPCLEANBUFFERS and DBCC FREEPROCCACHE.

These will ensure the proper independance of...