Viewing 15 posts - 53,701 through 53,715 (of 59,072 total)
This was an awesome articles and it spawned a great discussion.
But the question of whether or not you can disregard the physical layer depends on your goal. In most cases...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 10:41 pm
I would disagree with your assertion that set based programming is code that touches rows once or very few times and that the query you specified is not set based....
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 10:25 pm
TheSQLGuru (12/6/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 9:56 pm
Thanks for the feedback, Matt... and thanks for the "missing link" info... I just fixed it.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:26 pm
Charles Kincaid (12/6/2007)
As a developer I'm not limited to doing EVEYTHING in SQL. For SQL2K I just count the rows coming into...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:21 pm
"Set-based" refers to a logical construct--the programming model. "RBAR" refers to a physical implementation of the solution (at least as you use it in the article). I assert that the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:11 pm
sing4you (12/6/2007)
That was an excellent article. I look forward to seeing the workaround!Thanks.
Thank you for the both the feedback, and the encouragement!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 7:11 am
Jason Selburg (12/6/2007)
Jeff Moden (12/5/2007)
....... I finally got 2k5 and will have to load it before comparing the methods to the RANK methods for running counts performance wise.
Well it's about...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 7:09 am
Heh... that makes a pretty cool sounding acronymn, too... "SbS" 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 7:08 am
"Interesting, but where's the hint as to how to avoid/mitigate the problem?"...
In case you're interested, a simplified explanation of problem is invoices that get queries raised.
Yeaup.... that's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 7:05 am
Hi Jeff,
thanks for this article.
A solution to this problem is to use procedural code (at least for SQL2K).
Probably not the intention of the author... 😀
Thanks for the feedback and...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 6:59 am
Heh... lost leader for one or two articles coming up... forgot to mention that in the article... sorry about that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:40 am
Does 1.txt exist in the same directory as where you are running the command from? You'd be better off using a full path name or, if not on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:36 am
I'd recommend a separate process to go get the data instead of trying to do reporting through a linked server. Setup a staging area to hold the data locally/temporarily.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:28 am
It's easier to find missing ID's... this test code shows you how... last paragraph of code is the code that does the work... everything else is just test setup...
--===== Setup...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2007 at 12:26 am
Viewing 15 posts - 53,701 through 53,715 (of 59,072 total)