Viewing 15 posts - 58,666 through 58,680 (of 59,063 total)
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
Senthil,
I'll probably get a real blast of hooey
for using Dynamic SQL but don't much give a rat's patooti
because it runs in...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 10:10 am
Subhash,
For the first problem, use the UNION query you made as if it were a table and do the GROUP BY on that... like this...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2005 at 8:47 am
declare @dbname varchar(100)
set @dbname = 'Some Database'
DECLARE @sql VARCHAR(8000)
SET @sql = 'use ' + @dbname
+ ' dbcc shrinkfile (''File'', Size)'
EXEC (@SQL)
...should work for what...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 25, 2005 at 8:13 pm
I don't beleive that moving the SELECT into a transaction will prevent others from writing to the target table and, therefore, will not prevent you from inserting a duplicate ID...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 25, 2005 at 7:58 pm
Viewing 15 posts - 58,666 through 58,680 (of 59,063 total)