Viewing 15 posts - 55,051 through 55,065 (of 59,072 total)
Sure... when you first create a server instance, they are not there. They only appear when something first needs them... then, they persist.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:40 pm
Um... be careful in that assumption... while this works...
DECLARE @SomeDate DATETIME
SET @SomeDate = '05.24.2007'
PRINT @SomeDate
...this will not...
DECLARE @SomeDate DATETIME
SET @SomeDate = '24.05.2007'
PRINT @SomeDate
...because the implicit format is understood to be mm.dd.yyyy.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:39 pm
Still worth it... maybe someone else can get a leg up on things if they manage to find it...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:29 pm
"Error like this object already exists?" What on Earth are you doing with the Dynamic SQL?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:18 pm
What... and miss out on all that high-class entertainment? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:16 pm
Duplicate records DO happen on staging tables used for preprocessing rows from third parties, especially telephone companies... Either a "UNIQUE WITH IGNORE DUPES" index must be used (comparitively very slow)...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:16 pm
Heh... you're right... wrong article... it was about "RAAS", not "RAC"...
You'r still nothing more than a spammer... I can't understand why you don't get your product evaluated on this site......
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:12 pm
This should do it nicely... classic cross-tab... you might be able to use SQL Server 2005 PIVOT as well... either way, it'll solve your slowdown because each row is only...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:33 am
Now... that's a bummer...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:16 am
Spot on, Vladan ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:12 am
Also, be aware that this method uses a "Triangular Join" which can get very slow if the "triangles" are allowed to get to any size... they can be hundreds of times...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:11 am
So, why not post how to make a "Numbers" table or provide the actual link? Aren't we a full service shop? ![]()
Venkat... here's how...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:05 am
Karthik,
I get it from your description... Can't work on it right now because I'm on the way to work, but I've got to ask...
Why doesn't "he" want these flattened out...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 8:01 am
The article was nice and simple... shows how to make and exec a proc that uses a table parameter.
What I'd like to know (and anyone can certainly answer) is why...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 7:44 am
Heh... more spam... at least the table example works, Rog... Saw the free code you guys posted for RAC and apparently a lot of the stuff doesn't work correctly...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 7:39 am
Viewing 15 posts - 55,051 through 55,065 (of 59,072 total)