Viewing 15 posts - 54,346 through 54,360 (of 59,098 total)
I agree with David although Carl is spot on technically... lot's of folks think of a "work table" as a sort of permanent temp table where no damage will be...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 10:36 pm
Just in case all the soft answers haven't made an impression...
If you use *=, you will suffer death by SQL 😉 Don't use it.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 10:29 pm
Just an observation... although you might be able to get away with it a lot of times, not having a column list associated with the INSERT part of an INSERT/SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 10:24 pm
...and, if you have less that 250 or so databases, the following will beat the pants off your cursor 😉
[font="Courier New"]--===== Declare local variables
DECLARE @sql VARCHAR(8000) --Holds the dynamic SQL
--=====...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 10:15 pm
Line 24 is the USE statement that you currently have commented out... the operand of the USE statement cannot be a variable. You will need to use dynamic SQL.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 9:57 pm
Wouldn't it just be easier to create two identical tables... have a surrogate passthrough view pointed at 1 for access while the other is being loaded. When all done...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 9:51 pm
Ummm... no... what doesn't make sense is why anyone would need to have more than 300 NVARCHAR(MAX) columns in a table...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 9:45 pm
Heh... that's why I sometimes hate BOL... here's the definition of "subquery" according to BOL which, incidently, agrees with Ramesh's definition...
A subquery is a SELECT query that returns a...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 8:03 pm
TheSQLGuru (11/5/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 7:11 pm
sdjuricic (11/5/2007)
Reason why we are using temporary tables in oracle is that we have a query engine that besides doing sql queries on a relational database it...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 6:42 pm
JJ B (11/5/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 6:01 pm
Andy Warren (11/5/2007)
As a consultant its rare that...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 5:43 pm
The reason I asked is that I produced two identical actual execution plans, one of which was less code, and which also proved Sergiy wrong, and you stated that the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 5:35 pm
That's a great article, Andy... I've never seen justification of doing it wrong put so eloquently. 😛 The problem with even the Type II Technical Debt is that...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 7:39 am
I'm thinking "interview", "test", or "homework" question 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 7:20 am
Viewing 15 posts - 54,346 through 54,360 (of 59,098 total)