Viewing 15 posts - 53,641 through 53,655 (of 59,089 total)
Mike Levan (12/11/2007)
sorry its deleted
That's just not nice... now we have an answer with no question.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2007 at 2:18 pm
I guess my question would be... why does anyone pass more than 8000 bytes of parameters to a stored procedure... what is the purpose?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2007 at 2:17 pm
If it's that critical, create a "token table" where you set a row to identify if the job is already running. Check for that token at the beginning of...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2007 at 2:11 pm
karthikeyan (12/10/2007)
Jeff,No..This is a different one.Yes i want to print ascii values of A-Z.
Can i use the same logic where you replied for my previous question ?
No, it's not different......
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2007 at 7:42 am
Ok... sure...
In order to do what you wanted, you wrote a loop to have a variable (@InitialValue) count from 1 to 6 in your first example. Then you...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2007 at 7:35 am
1. What is the best way to show rows of data here? I am sure the way I did it can add to confusion if a lot of columns of...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 7:23 am
Heh... Exactly... couldn't have said it better myself!
... and... GO WINGS! WOO-HOO!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 7:15 am
Karthik...
What about you... you all set?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 7:06 am
I delete dups like this all the time:
delete d
from table k
join table d on k.matching = d.matching
where d.primarykey < k.primarykey
And I could swear this is set based, but maybe it's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 7:00 am
Ramesh (12/10/2007)
Apparently, you would be surprising to see some useful features disappeared!!!:D
Heh...you've got that right...
Thanks for the info, Ramesh... add one more chunk... the scripting options you told me about...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 1:48 am
First, you must make the dates correct... the following code exemplifies the error... run it an see...
DECLARE @AnyDate DATETIME
SET @AnyDate = '12/8/2007'
SELECT @AnyDate + '11:59:59.999...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 1:40 am
You bet, Sandy... thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 1:27 am
If all the SKU's start with a numeric digit and nopne of the paths leading to the file have a digit anywhere in them, then the following demo code gives...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 1:25 am
You are double posting... that'll get you thrown out of the "sandbox"... 😉
http://www.sqlservercentral.com/Forums/Topic431176-8-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 1:10 am
Of course the "code" must change... but the changes I made also make it more flexible...
DECLARE @Str VARCHAR(100)
SET @Str = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
SELECT LEFT(@Str,Number)
FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2007 at 12:40 am
Viewing 15 posts - 53,641 through 53,655 (of 59,089 total)