Viewing 15 posts - 51,076 through 51,090 (of 59,091 total)
You bet... let us know how things work out for you...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 7:17 pm
escaleraroyal (4/16/2008)
Vendor says the same applicationX runs fast in another company1 which has a higher volumne of data. He thinks it's our clustering server that is causing the issue as...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 7:11 pm
martin scott (4/16/2008)
The data is from an sql table stored at the lowest level ...
Then, post the CREATE TABLE statement and some example data as outlined in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 7:08 pm
You life depends on this...
You need to answer a couple of questions...
1. Would you be happy with a non-dynamic SQL solution?
2. Are any TEXT, NTEXT, or IMAGE...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 7:05 pm
Nope... they would fall in the category of "abusers" or "Know-It-Alls"... heh... Know-It-Alls... funny how the abbreviation for that is "KIA"... 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 7:00 pm
If there is no difference between the DTS jobs, check both servers using the DBCC USEROPTIONS command... look for what the setting in the "dateformat" setting is. Compare the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 6:56 pm
And, just a note... all the data should be stored vertically instead of horizontally... it should only be pivoted or cross-tabbed for display purposes... would make your calculations a whole...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 1:59 pm
Yeaup... that's the one I used. Works fine, fails safe, and drains to the bilge. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 1:56 pm
GSquared (4/16/2008)
Jeff Moden (4/16/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 1:21 pm
Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 9:34 am
True enough... you won't always be able to use something like INNER MERGE JOIN because the optimizer doesn't always like it.
Teaching a man to fish... the WITH RECOMPILE option is...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 9:27 am
Dang... I keep forgetting about that... thanks for the reminder, Matt. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 9:21 am
corey.psychological (4/16/2008)
aaah SPOT ON!!:D:D:D:D:D:D:D:D:D:D:D:D:D
THANKS ALOT FOR THE HELP!!!!!!!
Heh... you did it... you took the time to post some simple table structures and some data. You made my day because...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 9:16 am
SELECT RateID, CONVERT(CHAR(8),CAST(SUM(CAST(EndTime - StartTime AS FLOAT)) AS DATETIME),108) AS TotalHours
FROM ConsultancyDetails
GROUP BY RateIDYou can't sum the difference between two date times... but...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 2:13 am
Hey Highway! Don't give up, yet... turn this into a learning experience because Sergiy is correct... no matter where you go, you're going to run into steaming piles of...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 1:22 am
Viewing 15 posts - 51,076 through 51,090 (of 59,091 total)