Heh, heh, heh.... leave it to Serqiy to just say it like it is   Splitting the tables like this is, in fact,...

Fabiano,

Ok... that's about 40 characters per select including the UNION ALL... that's only 100 tables if you use VARCHAR(4000) or NVARCHAR(4000).  So, use VARCHAR(8000) and just use EXEC... don't use...

Just a note folks... anytime you use a column name in a formula in the WHERE or ON clause of a SELECT, you make it impossible for the coveted INDEX...

Serqiy beat me to it!   STOP USING SYSTEM TABLES FOR SUCH SIMPLE CHECKS!!!  Use the system functions like Serqiy did.

Oh... no, no, no, no... ISNUMERIC does not adequately test for IS A NUMBER or IS ALL DIGITS...

Try this...

SELECT ISNUMERIC('$1,000')

SELECT CAST('$1,000' AS MONEY)

SELECT CAST('$1,000' AS INT)

GO

SELECT ISNUMERIC('0d05')

SELECT...

Fabiano,

What is the pattern of you table names?  And are they in the same database or different databases?  I have the same problem with some 3rd party software at work...

You did all the hard work... I think this is probably what you're looking for... the changes will group your output by date and hour...

select

DATEADD(hh,DATEDIFF(hh,0,Time_Perf),0) AS Date_Time,

avg(total_processor) as 'total...

Storing anything of that nature in tables is generally a bad idea... instead, store just the UNC (\\machinename\path\filename.ext) and pass that to the app... then let your app go get...

You'll need to use UNC's instead of file/path.  Example... \\Machinename\path

Didn't know that and you are correct... usually an ALTER TABLE ALTER COLUMN doesn't require that very long method the EM builds... it is, however, crash proof.  So there's a...

Not sure why you don't just let the tools do it for you... if you use EM to make the change, it will do everything for you... no fuss, no...

You had an Assembler?  Lucky you... Much of the code I wrote in the "good old days" was hand-assembled machine language... now THAT was fun

Looks like I'm not the only one that can't sleep... thanks, Prasad.

And they say understanding underlying data structures is no longer important... the '00' unicode country code in these examples sticks out like a sore thumb to anyone who has seen...

Conversions are a bit costly performance wise... the following works approximately 45% faster on a million row test...

 SELECT DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)