Viewing 15 posts - 52,696 through 52,710 (of 59,072 total)
Philippe Cand (1/31/2008)
Wether or not something is supported by Microsoft does not make it safer.
It is all about probability and bugs....
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 9:36 pm
James Goodwin (1/31/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 9:21 pm
However, the engine has no obligation to scan the table in index order, as there are no language constructs which impose an ordering on the execution order of a scan....
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 9:11 pm
Ian Yates (1/31/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 8:47 pm
ALZDBA (1/31/2008)
There may be some testing needed regarding parallelism,
maybe for now just add a OPTION(MAXDOP 1).
The only remarks I would add to the conclusion...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 8:35 pm
Christian Buettner (1/31/2008)
very interesting article.
Somehow it throws all my beliefs into the trash bin:
1. The update method with variables is not explicitly supported by Microsoft
2. The clustered...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2008 at 8:28 pm
According to a recent radio ad by one of the better known railways, freight trains use only 1 gallon of fuel to haul 1 ton (2,000 pounds) 443 miles... we...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2008 at 10:48 pm
Yep... thanks for the feedback. I've seen that, too. But only on SELECTs... and only on non-clustered indexes. I've never seen it fail on UPDATEs on CLUSTERED...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2008 at 10:41 pm
Heh... don't forget about DBCC SHOWCONTIG WITH TABLERESULTS
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2008 at 3:58 pm
Didn't you read any of the above? Don't use ISQL... use OSQL or SQLCMD depending on which version of SQL you have.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2008 at 6:08 am
bonk (1/29/2008)
I agree with you! But there's nothing to do in this case. I explain: the table with one column for each month already exists and I can't modify...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2008 at 5:59 am
It's because ISQL is just a subset of what the server can actually do. Do NOT use ISQL. Use OSQL instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 29, 2008 at 8:03 am
I agree with Matt... recursion is probably not the best way to do things like this...
There are variations on this theme but here's a nice little NON-recursive CTE that...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 29, 2008 at 7:59 am
It that case... might be OSQL... THAT does have such a set of switches... if memory serves, "-h-1" (no spaces, no quotes) would be the switch you're looking for.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2008 at 2:02 pm
I would like to know how can I read a record from a table with 12 columns (each on for each month in a year) end put the value for...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2008 at 1:59 pm
Viewing 15 posts - 52,696 through 52,710 (of 59,072 total)