Viewing 15 posts - 47,401 through 47,415 (of 59,102 total)
... and please see the following article for some potential problems you can avoid with some other methods of concatenation...
http://www.sqlservercentral.com/articles/Test+Data/61572/
Jerry's method does not have such problems.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 8:07 pm
1
... and is TempDB large enough for the task and is auto-shrink on TempDB turned off?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 8:04 pm
Sorry... not enough info. Please refer to the link in my signature for quicker/better answers.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 8:02 pm
If the NVARCHAR column has no multi-lingual entries (the main purpose for NVARCHAR), the a simple SELECT CAST(columnname AS VARCHAR(x)) where x is the desired maximum length should work. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:56 pm
Probably because it's relatively slower than a Cross-Tab and not backwards compatible to SQL Server 2000 and may not be migratable to other RDBMS's.
So... without any real data to test...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:50 pm
That won't be a recurrsive query... it'll be a simple join between the two tables joined on ID.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:44 pm
Probably not what you want to hear, but I'm thinking that the OCR software, well... sucks and you may have to find some better software.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:39 pm
Guess that's where the term "It Depends" comes from... :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:26 pm
Heh... I see now... first, of course the rowcounts will be/are identical. And, of course your testing shows that WHERE IN will be much faster... you changed the problem...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:23 pm
Do your tests all come back with the same rowcounts? Remember... it's random data and SomeInt has different counts for different values.
And, no... I didn't get any Index Seeks......
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 7:13 pm
Heh... I believe I have it... ROUND just shouldn't be used for display purposes... in Books Online, they say...
This example shows two expressions illustrating that with the ROUND function the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 6:49 pm
I get the correct answers by copying and pasting the code directly from the original post in SQL Server 2005...
In SQL Server 2000, no dice... @a and @c both...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 6:34 pm
Heh... sure... you've done something wrong in the code. 😉
There is no way possible to figure out what's wrong from here with what you posted. Discounting all of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 6:23 pm
krayknot (11/4/2008)
It only depends on the number of rows you have in the dB and the number of resultant rows after applying the condition
Absolutely not true. Take a look...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 6:08 pm
Thanks for the feedback, Jorge. Let us know if there's anything else we can do to help.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2008 at 6:06 pm
Viewing 15 posts - 47,401 through 47,415 (of 59,102 total)