Viewing 15 posts - 57,091 through 57,105 (of 59,101 total)
Yep... whichever one ran first on my box, lost by about a second. Then, I removed the drop from both, whichever one ran first, also lost by about a second. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 9, 2007 at 5:47 am
The SQL Server "Service" must be logged in as a user that can "see" those remote paths. As Lynn said, that also means that user must have permissions to see...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 8:28 pm
Now, reverse the test... do it with the NO DROP first...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 8:18 pm
First, don't use ISQL... it's quite a bit deprecated when compared to OSQL which you should use instead.
Second, yes, both your BCP and OSQL should be very close... probably the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 6:26 am
Of course, we could stop guessing if you'd post the code, Ashok.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 6:18 am
Looks a lot like homework or a quiz... what have you tried?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 7, 2007 at 11:07 pm
Outer joins are not always the culprit in slow SQL... joining a bunch of tables and returning to0 many columns usually is. Also, the reason why adding indexes isn't helping...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 7, 2007 at 10:19 pm
Usually, the culprit is a CLUSTERED PRIMARY KEY... change it to non-clustered.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 7, 2007 at 10:14 pm
If you want it to be unique across days (11PM today is NOT the same as 11PM yesterday)...
SELECT ...
GROUP BY DATEDIFF(hh,0,PinIssueDate)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 5, 2007 at 10:30 pm
Ohhhh hold the phone right there... As much as I like Joe, his comments can really get out of hand... I don't care how good you are, no one has...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 10:34 pm
Or...
declare @tabla table(field char(20))
insert @tabla values ('AABBZ')
insert @tabla values ('AADDZ')
insert @tabla values ('AA-EZ')
insert @tabla values ('AA--Z')
insert @tabla values ('AA++Z')
insert @tabla values ('AA+EZ')
insert @tabla values ('AACCZ')
SELECT *...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 9:42 pm
John Rowan is correct about the existing rows... that's why some have suggested that the new column be a "calculated column" (see CREATE TABLE and ALTER TABLE in Books Online...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 7:57 pm
Lee,
I absolutely agree with Brian on this one... I'm still looking forward to part 2, as well. Don't let the flamers deter you... think of it like an iceberg... you...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 7:24 pm
Nope, with the second index in the code, I'm getting an INDEX SEEK on the OR method...
But I agree with the rest... why go through an index at all to...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 7:24 am
You say you've been working on it for "weeks"... let's see what you've tried.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2007 at 12:33 am
Viewing 15 posts - 57,091 through 57,105 (of 59,101 total)