Sure and understood... but, with proper indexing, good set based code, and the like, access will be extremely fast without having to go through a cache layer that needs to...

I still need to see how you're calling the proc because that might be part of your problem...

Heh... then there's shops like what I used to work for... I'd not only be the DBA, but I was also the OS guy, the guy that built the computer,...

Understood... but the interviewer from Microsoft asked why it's better to list all of the columns than to use Select *...

What would really be "cool" is Low Temperature Differential Stirling Engines. Design one that would work at 70-90^oF_d Diiferential (would be kinda large but light-weight) that would kick out...

Yep... maybe that too. Same thing goes with statistics, I suppose.

It just seems very odd to me that you want a DBA to drive your very expensive truck but you won't even let him/her check the pressure in the tires...

What are you using to call the proc? In other words, let's see the EXEC statement 'cause the code in the proc is mostly correct. Only thing wrong...

Heh... to many conversions and concatenation for me... the following does the trick as well...

SELECT STUFF(CONVERT(VARCHAR(30),GETDATE(),107),1,3,DATENAME(mm,GETDATE()))

The best answer would be "to protect the results". I've seen it happen before... DBA's can decide there's a problem with a table or they need to instantiate some...

Thanks for the feedback! Good to know that it wasn't BCP.

Heh... I'm still trying to figure out why anyone would try to cache a 54 million row table...

Step 1, I would think, is to hunt down the vendor that provides you with the information... and then yank their tonsils out through their nose. Wow! They...

You're welcome... thank you for the feedback.

You're welcome and thank you for the feedback.