Viewing 15 posts - 58,666 through 58,680 (of 59,067 total)
Try this, instead...
SELECT "This is a test"
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2005 at 3:46 pm
Why don't you just try it?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2005 at 3:40 pm
HRen,
You could certainly change the meat of this to a user defined function to, as they say, enforce an enterprise wide standard or if the output is required for something...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 3, 2005 at 9:23 am
Serqiy,
That might work fine on small tables but I stopped the run after 37 minutes just trying to return the first page on my large table... here's the code...
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 30, 2005 at 5:32 pm
Adam, I think part of the problem is, the formula doesn't work as everyone expects
because DATEDIFF only looks at boundaries crossed of the date part...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 30, 2005 at 7:21 am
As someone else suggested, why make the AGE persist? I'm thinking it would be much easier to add a calculated column to the table so that you don't have to...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 29, 2005 at 7:26 pm
Well, I retuested with the correction Giovanni noticed (see last posting) and was a bit surprised... the change did nothing to the low end (1st page still returns in 13 milliseconds)...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 29, 2005 at 5:20 pm
Giovanni... thanks for the questions.
The * selection in the top select of "d" was a nasty oversite
... it was a leftover from testing...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 29, 2005 at 5:06 pm
Subhash,
I'm sorry I left out the the "--" on the comment
. It sure did make a mess of things. You all set now?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 29, 2005 at 6:39 am
... or try Books OnLine which comes with SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 10:47 pm
That would do it, but be careful... setting the transaction isolation level in procs may sometimes cause a conflict for lock type. You could use the WITH (NOLOCK) hint after the...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 10:45 pm
Just so you know, you can use VARCHAR(8000) for this... won't help with things over 8000 characters like Peter's suggestion but you don't have to limit yourself to 4000 characters...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 10:23 pm
Better late than never, I guess...
DECLARE @Year CHAR(4)
DECLARE @NextYear CHAR(4)
DECLARE @ISOWeek VARCHAR(2)
SET @Year = '2001'
SET @ISOWeek = '53'
SET @NextYear = @Year+1
SELECT
CASE
WHEN...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 12:21 pm
Oh CRUD! No, you don't even want to think of building a sequence table for this... here's why...
You said that the 3rd party stuff ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 11:21 am
Kenneth is absolutely correct... if you're not going to use IDENTITY, then you really must have a counter/sequence table and a stored proc to get the nextid. Repost if you...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 10:57 am
Viewing 15 posts - 58,666 through 58,680 (of 59,067 total)