Quote from article:  "

All software is licensed on a per computer basis. For example, if you wish to use SQL Backup on more than one computer you will need an...

>> I got sidetracked by other issues and haven't got to any of the newer suggestions yet.

WHAT?!?! You mean you don't get to work on one task to completion?!?  OUTRAGEOUS!! ...

it is almost certainly query caching that is getting you in trouble here. 

do all your tables have an index on LST_DTE?  do you have indexes on the columns joined...

Without seeing the code, I would bet that either 1) you are hard-coding a variable or two in your where clause in query analyzer which allows the query optimizer to...

Irrespective of why the code snippet you produced is running slower on sql2k5, wouldn't it be MUCH faster to simply create a table with the rows you DO WANT in...

1) There are a number of 'improvements' to your query:

set rowcount outside the query

use explicit transactions and error checking

SET ROWCOUNT 10000    --I might go with 50K here?

Here is the link for those that are wondering:  http://www.sqlservercentral.com/scripts/viewscript.asp?scriptid=1243

There were a number of quite contentious threads some time ago about how the sql server user community will lose...

Colin, your query does exactly what I cautioned against.  Suppose a line of a sproc wraps in syscomments (nvarchar 8000 IIRC), and it wraps in such a way to split...

Since you are a newbie to SQL Server (and appear to have been thrown into the deep end of the pool I will...

Be careful though.  Sysdepends is not guaranteed to be accurate at all times.  The most thorough way is to grep through syscomments with a LIKE clause of  '%tablename%' and join...

Jurriaan, you should definitely NOT create the index before populating the data.  This will simply lead to a very fragmented index right off the bat.

Well, if you build a clustered index it is gonna hurt!  The entire table may well be rewritten out to the transaction log as the data is sorted and laid...

Proper sizing of disk files for databases is something that is optimally done by the DBA, not by sql server hitting a full file and then auto-growing the file based...

You mentioned doing data mining so I will assume that you actually DO need all the data from the day's join query so you can run it through some mining...

>> That is correct as long you give the access to the db through application but I have seen the cases sometimes clients want to generate custom reports which requires...