Viewing 15 posts - 58,846 through 58,860 (of 59,063 total)
It's a bit difficult to believe that you would ever have a NULL StartDate with a valid EndDate. Normally, it's the other way around. But, no worries...
For NULL StartDates, I...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2005 at 7:49 pm
Antares,
I apologize if the time lag between our posts caused this...
I had reposted a solution as follows...
STUFF(STUFF(REPLACE(STR(Run_Time,6),' ','0'),5,0,':'),3,0,':')
The original question was how to convert the Run_Time column of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2005 at 6:56 am
p.s.
If you are getting a "NULL' as a return, perhaps the code you wrote isn't actually finding what you think. Post your code and we'll take a look.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2005 at 6:36 am
Schalk and Antares,
I test this stuff before I post it and, you are incorrect. STUFF works just fine on an INT values thanks to implicit conversions. For example, this...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2005 at 6:27 am
Autogrow = Fragmentation
As some have already said on this thread, set TempDB to be a reasonably large initial size and set autogrow to100 to 500 mb. We currently have a...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2005 at 10:04 pm
Since the column is in the format of HHMMSS (even though it's a number),
For just a pure string representation of the time...
STUFF(STUFF(run_duration,5,0,':'),3,0,':')
For a real time as a...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 26, 2005 at 9:57 pm
You may experience some "wierd" answers when using FLOAT because it does it's math in a binary rather than decimal fashion.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2005 at 2:01 pm
The problem is most likely that the datatype in one of the columns is FLOAT which using binary math instead of Decimal math with some very unexpected results. Recommend you...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 14, 2005 at 9:32 pm
I believe that your outer parenthesis are the problem. Compare your script tot the previous answer.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 14, 2005 at 9:28 pm
> If you are using this for a one time query, you really will want to do it that way
... unless the return is very large in which case you'll...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 14, 2005 at 9:15 pm
There is if you update other fields along with the "cased" field. Nulls will be put in the "cased" field.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 14, 2005 at 9:11 pm
Just to dispell some of the drum beating on this thread, I've asked 22 different SQL programmers and DBAs in some pretty large companies, some of which were related to...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2005 at 11:19 pm
First, Adam, thanks for the great link. I took a look at ALL of the scripts including the additional reference to the auxiliary number table and I definitely see your...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2005 at 6:03 pm
Very nice. The graphics you took the time to do the "Alice's Restaurant" thing to really make this a very clear article on what Rollups and Cubes actually do. The...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2005 at 6:37 am
Again, lot's of good posts. Shie, Robert L, Noeld, and Adam have all pointed out that the use of a "Calendar Table" or "Holiday Table" to hold non-workdays (I'm assuming...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2005 at 5:43 pm
Viewing 15 posts - 58,846 through 58,860 (of 59,063 total)