Viewing 15 posts - 56,941 through 56,955 (of 59,101 total)
Hey there Harley,
Thanks for the compliment... You and Paul made my day!
Sadly, in SQL Server 2000, there's no way to return the equivelent of row numbers using a SELECT without using...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 1:10 pm
I do not think there is a way where you can use Update to update based on counter |
I...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 1:03 pm
Hey Paul,
I almost forgot a trick with using this if you can't make a "sister table".... you can force the order by using an index hint... like this... (this is...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 1:00 pm
Heh... thanks, Paul... I always wonder if anyone reads these things... ![]()
Just so you know I'm not using some whacko, back door, undocumented construct,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 12:30 pm
My 2 cents... IDENTITY column on table "A" with trigger on table "A" that adds 1 to that column to store in table "B". Then, kill the person that designed...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 11:26 am
Maybe I misread and, if so, sorry...
If CMRGDT is an integer, I don't think that WHERE CONVERT(DATETIME,CMRGDT) > GETDATE() - 2 is going to work without an extra conversion like...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 9:42 am
I'm not sure, Lowell, but have you tried converting the DLL to an "extended stored procedure"? Books Online tells how...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 9:32 am
Since I'm mostly a data troll, I don't know what language you are writing in, but I'll give it a shot even though this is Oracle... replace the "&" with...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 9:30 am
As a side bar... if your trans_date has time in it... don't use BETWEEN because it will ignore most of the end date. For that same reason, you shouldn't use...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 9:22 am
Just for grins... the following two items are functionally equivelent...
CASE
WHEN MONTH(ledger.trans_date) < 7 THEN MONTH(ledger.trans_date) + 6
WHEN MONTH(ledger.trans_date) > 6 THEN MONTH(ledger.trans_date) - 6
ELSE 13
END...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 9:10 am
A slightly different take on David's 2 character solution...
REPLACE(CHAR((Number/27)%27+64)+CHAR(Number%27+64),'@','0')
Just remember that both of those 2 character solutions "lose their mind" at a decimal value of 730... David's starts producing special characters...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 7:37 am
Heh... Thought I explained it just fine... Tim, the key for me was the value 1 being A, 26 being Z, and 52 being AZ... I should have said, "I don't think you want...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2007 at 5:55 am
Ok... in the absence of a response about what the primary key might be...
First... no loops... think set based... loops just slow things down.
Second, I can only believe that you...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2007 at 9:42 pm
Hey there John, I think you'll like this...
First, your numbering is a bit off... if 1 is "A", and 26 is "Z", and 52 is "AZ", then 53 MUST be...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2007 at 9:04 pm
No matter which way you do it, we're going to need to know what the primary key for the table is.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2007 at 7:35 pm
Viewing 15 posts - 56,941 through 56,955 (of 59,101 total)