Viewing 15 posts - 47,776 through 47,790 (of 59,095 total)
I appreciate your concern about future posts... but more immediately, are you all set with the current post?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 8:56 pm
Your toast... sorry...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 8:49 pm
Peso (10/12/2008)
Jeff Moden (10/9/2008)
G Bryant McClellan (10/8/2008)
Michael,Ummm.... both table variables and temp tables start out in memory and "jump" to TempDB when they overcome some point in memory.
Really?
I was under...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 8:39 pm
Sure... here's one I was "playing" with and never did go back an finish... It stinks because of all the correlated subqueries... probably gonna be terrible for performance.
DECLARE @SomeNumber VARCHAR(25)
CREATE...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 9:32 am
I would imagine that it would be done the same way as they told me above.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 9:17 am
GilaMonster (10/12/2008)
And, heh... guess I'm still angry at the fact that the DateTime2, Date, and Time won't convert.
Why? Other than conversions I haven't found a good reason to convert a...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 9:15 am
PaulB (10/12/2008)
Jeff Moden (10/11/2008)Nope... for a decent size company, that's about what I'd expect except it might be missing the "Project Management" layer.
For some of the small companies I've worked...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 9:14 am
PaulB (10/12/2008)
Jeff Moden (10/11/2008)
Heh... and by the way... this...T - you do whatever transformation or massaging is needed...
... sometimes means deleting duplicated data. 😉
Nope. We do not delete on Staging....
--Jeff Moden
Change is inevitable... Change for the better is not.
October 12, 2008 at 8:27 am
GilaMonster (10/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 10:04 pm
johncyriac (10/11/2008)
...this particular database is in SQL 2000
Heh... [font="Arial Black"]SLAP!!![/font]
Scott's method will absolutely be the fastest. But, just in case you can't do anything to the table or can't...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 10:00 pm
Chris Harshman (10/11/2008)
D'oh! this isn't the first time I've given someone a 2005 solution to a 2000 problem, sorry about that.
Not your fault... this IS a 2005 forum. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 9:42 pm
Alvin Ramard (10/6/2008)
Someone slap me please! All I keep thing about is using a ...... cursor.
Slap... slap, slap... [font="Arial Black"]SLAP![/font]
Heh... Pork chops away!!! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 9:41 pm
Mike (10/11/2008)
PaulB (10/11/2008)
CIO
|___ PMO
|
|___ Infrastructure
| |
| ...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 8:17 pm
Garadin (10/10/2008)
The IN clause is actually faster than the multiple joins. I tested it on the Northwind database (so it was easily repeatable) as so:
I ran your test code...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 8:07 pm
This is a cross post. Please don't post solutions here. Go to the following post, instead...
http://www.sqlservercentral.com/Forums/Topic584480-338-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 7:57 pm
Viewing 15 posts - 47,776 through 47,790 (of 59,095 total)