Viewing 15 posts - 58,516 through 58,530 (of 59,091 total)
GM beat me to it but using his test, I came up with the same correct results all 3 times...
SortOrder,Letter
0,e
0,b
1,a
1,f
1,c
2,d
2,g
Ryan, Yep, I tried it and you are correct (I forgot...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2006 at 7:12 am
As the article warns, this method makes use of a correlated subquery that forms a triangular join which is half a cross join. It will crush any hopes of performance...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2006 at 8:35 pm
You do not need to enable full text features to use SOUNDEX or DIFFERENCE...
DECLARE @Str1 VARCHAR(100)
DECLARE @Str2 VARCHAR(100)
SET @Str1 = '129 Green Ave'
SET @Str2 = 'Green...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2006 at 8:24 pm
If tl.Date is a DateTime column to begin with, you don't need to do any of that.... the Order By tl.Date will work correctly even though you've Cast it in...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2006 at 8:03 pm
I'm still curious... why did you want to join two tables that have nothing in common to join on?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2006 at 7:58 pm
That's what I thought... thanks for the feedback, Trigger.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2006 at 7:43 pm
Just a reminder, folks... xp_CmdShell requires SA privs or a proxy login that has SA privs.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2006 at 3:25 pm
Pat,
Basically, any legal expression may be used so long as it does not refer to another table. Cast and Case may be used. SELECT may not because it's a "clause"...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2005 at 1:02 pm
Nope... it's not... SET ls_action=0 will fail in the absence of other code. You either have to declare ls_action as variable (don't forget to add the @ sign) or you have...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2005 at 12:37 pm
Daniel,
The other thing you may not be aware of is that if you update ANY column in the table that has a timestamp column, the TimeStamp will change. I think...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2005 at 12:27 pm
Ok, thanks... you sure you wanted the duplication in the #QueryTable? Could get pretty nasty if you have lots of rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2005 at 12:05 pm
Steve and Ken...
Yup, I knew that... I just thought that since Trigger recommended it as a T_SQL command, there might be some neat trick he was using to use it...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2005 at 12:02 pm
Yup, your method works just fine (but what a pain with all of those indexes). And, deleting the "dupes" probably wouldn't be any faster because of the indexes.
And, to answer...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2005 at 10:30 pm
Trigger,
How do you use BCP from T-SQL without using xp_CmdShell which is normally off limits to all but those members of the SA role?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2005 at 10:15 pm
Thgamble1,
Carl has the correct answer here... did it work for you or do you still have a question?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2005 at 10:07 pm
Viewing 15 posts - 58,516 through 58,530 (of 59,091 total)