Viewing 15 posts - 59,011 through 59,025 (of 59,095 total)
Rohit,
The setbased logic you used in your example will almost always beat Cursors and WHILE loops. Do you need any reason other than speed? Ok, how about resource intensity, duration...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2004 at 9:37 pm
Sukio,
There is an example query in "Books on Line". To find it, lookup "expanding hierarchies" in the BOL index. Be advised that it is not "bug free" and will require...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2004 at 9:13 pm
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2004 at 9:59 pm
This should do it with some assumptions... the assumptions are that you will have no title (Mr., Mrs., etc) and no suffic (Jr. Sr. II, III, IV, etc).
/******...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 23, 2004 at 8:59 pm
David,
If Edward is correct and all you really want is to split the last name from the rest and we assume that the last name will appear after the last...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2004 at 6:27 am
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
Viewing 15 posts - 59,011 through 59,025 (of 59,095 total)