Viewing 15 posts - 58,996 through 59,010 (of 59,075 total)
You have to convert @Count to VARCHAR or CHAR
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2004 at 4:58 am
Hi Midan,
Guess there might be a little problem with the language barrier thing... let me see if I can clear it up...
I believe your problem is that you want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 6:56 am
Sukhoi,
I don't know if the little bit of "language barrier" between us is a problem or if I'm just misreading this... just want to make sure you aren't stepping onto...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:38 am
Sukhoi,
Again, as in the post I answered for you previously, you need to do some conversions in the concatenization. You have to CONVERT the date to VARCHAR or CHAR. See...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:29 am
Sukhoi,
It's funny how the error message is sometimes the opposite of what it should be...
Your problem is that the contents of one or more of your variables are numeric and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:24 am
You never mentioned how long it was taking for the update...
My experience for these two table type of single column update joins says you'll get about 4 million rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2004 at 5:32 pm
paolice,
Understood... I use "trial and error" a lot. But you still haven't given me a clue as to how to use DataLength to determine the defined length of a column. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2004 at 5:18 pm
Thanks Antares... didn't know that.
Hey paolice... how do you get DataLength to return the "defined length of your table's columns"? Couldn't find a thing about that in BOL.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2004 at 5:42 pm
Errrr.... not sure just exactly what you're looking for so I offer this simple example on how to use a rowset from a stored procedure....
USE PUBS
GO
SELECT a.*
FROM OPENROWSET('MSDASQL',
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2004 at 8:19 pm
Unless it was a text or ntext field, why would you use "DATALENGTH" over just "LEN" like some of the other replies used?
Just...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2004 at 7:17 pm
Demicog,
To remove the first character of a column, no matter what the character is, try this...
SELECT SubString(columname,2,999) --Sub the "999" with the max width of the column
To remove...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2004 at 10:27 pm
Here's a different way...
DECLARE @DesiredLEN TINYINT
DECLARE @FillChar CHAR(1)
DECLARE @ResultString VARCHAR(255)
SET @DesiredLEN = 25
SET @FillChar ='#' --So you can...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2004 at 9:32 pm
Heber!
I've been looking for a really simple way to "add a running number" to a SELECT for a long time! Thank YOU! That IS a really neat trick!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2004 at 9:20 pm
David,
Thank you for your kindness...
I've sent the code samples to 4 different people and have run it on the server at work. In every case, your code with the <>...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2004 at 7:17 am
David,
I'd say that I owe you an apology!
Your code does, in fact, return all of the rows expected! I don't know what I...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2004 at 6:16 am
Viewing 15 posts - 58,996 through 59,010 (of 59,075 total)