Viewing 15 posts - 52,411 through 52,425 (of 59,091 total)
Yes, you can save the result set in a table by using a kind of "back door" way using a call to OSQL....
--===== Create a temp table to hold the...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 6:51 pm
Yeah... I know, I know... thanks guys...
Sticknyn... don't let them scare you off, Man... if you know a way to pass a table variable in 2k5, you've just gotta tell...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 6:25 pm
stricknyn (2/21/2008)
I can pass a table variable into a stored procedure that has a table variable as a parameter.
You can? And it works? Would you mind...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:43 pm
All I can say is, CRAP!!!!!
As pjancicka states, it works fine on 2K SP3a, and doesn't work correctly on anything after that!
Hey! Some of you MVP's...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:20 pm
Myschif,
Adam and the other folks are too kind with their words about my articles. The articles do, however, explain some major pitfalls with the performance of some of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:11 pm
I saw you in the post, Adam... I knew you would do as good as I could. And, thanks for the plug!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:02 pm
Shiv (2/21/2008)
I have given that direction as parameter bcos i want use it like a condition there. That's not problem I can just keep 'queryout' there directly instead of direction...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 11:52 am
Matt Miller (2/21/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 11:50 am
Heh... sure you did... you learned that there's more than one way and that one of the ways will be easy. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:24 am
I understand... if "every code change can be acceptable", then consider implementing that which is found at the following URL:
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:12 am
What is the exact wording of the error?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:22 am
Yeah... it's a simple "Name/Value" table that can easily resolved using various high performance methods (none of which require a CLR) including simple cross-tabs. What kind of an error...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:20 am
Simong,
Here's a simple "splitter" to normalize the CSV entries you have so you do a join instead of a "LIKE"...
--===== Create a table to hold user ids and a word...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 4:38 pm
tbeadle (2/20/2008)
[font="Arial"]There are word token subroutines available to help with loading the single field table.The comparison of the two table entries would be fairly simple at that point.[/font]
Good thoughts, Terry......
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 4:12 pm
Either way, looks like a correlated sub-query is going to be involved which is why Matt suspects the performance is going to suck a bit...
Here's another way (output could be...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 3:42 pm
Viewing 15 posts - 52,411 through 52,425 (of 59,091 total)