Viewing 15 posts - 58,291 through 58,305 (of 59,067 total)
Noeld,
I haven't figured a way around it yet but the function needs to return a "5" instead of the "1" it does for 02/01/2006 according to what the user posted...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 19, 2006 at 5:46 pm
Different slant...
EXEC sp_SpaceUsed yourtablenamehere
--Jeff Moden
Change is inevitable... Change for the better is not.
April 19, 2006 at 5:26 pm
This may be a little faster... replace the #30 with the defined width of the column (or more)...
SELECT SUBSTRING(somevarcharcol,PATINDEX('%[^0]%',@String),30)
FROM yourtable
--Jeff Moden
Change is inevitable... Change for the better is not.
April 19, 2006 at 5:12 pm
Trys this instead...
SELECT CONVERT(VARCHAR(10),date,101)
... because the supbstring method on date castings will likely not five you the mm/dd/yyyy format that I think you're looking for. And here's some other formating...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 19, 2006 at 5:01 pm
...and thank you for the feedback...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 18, 2006 at 8:43 pm
Or... don't let it default to INT...
declare @DateOfInterest datetime,
@EpochDate datetime
set @DateOfInterest = '12/11/1962'
set @EpochDate = '1/1/1970 03:00'
select CAST((@DateOfInterest - @EpochDate) AS DECIMAL(24)) *24 *60 *60 *1000 as n
--Jeff Moden
Change is inevitable... Change for the better is not.
April 17, 2006 at 9:38 pm
Short, simple, nasty fast because there are no VARCHAR conversions...
SELECT DATEADD(mm,DATEDIFF(mm,0,GETDATE()),0)-1
--Jeff Moden
Change is inevitable... Change for the better is not.
April 17, 2006 at 9:29 pm
I agree... I always spell them out all the way...
I don't believe BOL calls them "alias names" though.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 17, 2006 at 9:26 pm
The scripts offered will certainly work (although you may want to add WHERE so.XTYPE = 'U' to filter on tables only), but tell me please... why would you want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2006 at 9:14 pm
Not quite true... JOIN is an acceptable shortcut for INNER JOIN. Additionally, LEFT JOIN, RIGHT JOIN, and FULL JOIN are acceptable shortcuts for the similarly named OUTER counterparts...
USE Northwind
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2006 at 9:03 pm
Ben,
Why not make the ConsultancyBookingNumber column in the Consultancy table and IDENTITY column instead of using MAX+1? Then, you wouldn't even need this procedure as the column would be auto-numbering...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2006 at 8:44 pm
Nicely done... You should publish this in the "scripts" section of this forum.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2006 at 8:33 pm
Although the DATEADD/DATEDIFF method will sometimes return a faster duration, it is slower than "convert(datetime,convert(int,GetDate()-.5))" if you consider actual resources used like CPU Seconds and DIsk Reads and Writes. Here's...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2006 at 11:13 pm
I just can't bring myself to trust anything in an article where the author makes mistakes like the following...
"Remember that the BETWEEN clause retrieves values that are equal...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2006 at 10:22 pm
David wrote... "If I was to use the static table approach I would probably stick it in its own database so that it wouldn't artificially inflate the backups."
Yep, I know...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2006 at 6:19 pm
Viewing 15 posts - 58,291 through 58,305 (of 59,067 total)