rather than looking at recompiles and statistics, how about looking at your joins themselves.

would it be possible to have 2 versions of the proc - each with distinct join...

you can also try using SET FMTONLY on/off

will execute the query, but not affect any rows or return rows (only metadata)

this would show up errors better than parseonly for missig...

as long as it's fast and useable i don't care (or want) fancy flash animations, button rollovers etc. I want to find and post data fast.

on another front how about...

the error indicates that it's attempting to use mm/dd/yyyy date format - possibly due to your login set to English rather than british, or dateformat settings

try

where Date >= '06/13/2006'...

as i said in my post - it's bad practice - we wouldn't do it, but the forums are here to help not to preach about what developers SHOULD be...

does your DNS server/PDC reboot at any point?

if @@servername returns different to serverproperty('machinename') then it's possible your server has been renamed??? - that MIGHT acount for the .\accountname not working correctly ????

you can rename your sql instance...

the script located here

http://www.sqlservercentral.com/scripts/viewscript.asp?scriptid=1541

would give you a good starting point

it was designed to move indexes from one filegroup to another, but it could easily be modified to create a file...

i would suspect something shutting the service down - look for a sheduled job in sql agent or windows sheduled tasks that does something along the lines of

xp_cmdshell 'net...

this really depends on how big your tables are.

if you only have small tables then there won't be any impact of auto stats, but for alrge tables (say for...

Steve,

have you tried scripting out "Enterprise mangler" code? great for small tables, but it has a tendency to be backwards compatable and Drop the table and recreate it....

the ordinal position CAN matter. Not everyone writes good SQL or applications and you can often fid yourself with "Select *" or "insert into x select *" in which case...

using convert(real,0.10) will give you the correct answer, but only because the precision is lower. - you may still get the same problem...

you might try creating this as an inline...

i wish - i'm in the office

select convert(float,rate)

however float is an approximation, so beware the type conversion - you may find some = operations do not return the results you would expect.

you should also be aware...