Viewing 15 posts - 58,756 through 58,770 (of 59,076 total)
Don't forget that just subtracting 90 days using either method will not take you to midnight of the given day... the current time element will be included unless you do...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2005 at 10:49 pm
This'll work if you have a DBA that doesn't understand the merits of a date table and it's short enough to use in inline code if the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2005 at 10:36 pm
Hopefully, SP4 will fix some of the memory leaks. It came out this last Friday.
The problem in our shop used to be that no-one did a code review of other's...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2005 at 6:26 am
I second Carl's suggestion about turning AutoShrink off... AutoShrink causes several problems not the least of which can be severe disk fragmentation and long wait times when it does need...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2005 at 6:15 am
I don't believe I'd use a trigger for this because if the Oracle DB or the connection to it is down, then your SQL Server...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2005 at 6:06 am
I don't believe I'd use a trigger for this because if the Oracle DB or the connection to it is down, then your SQL Server processes will start kicking off...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 9, 2005 at 5:56 am
I believe that it's called an "M-Space" and occupies the same width as the letter 'M", hence the name. Since it's not a regular space character (ASCII 32), you may...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2005 at 10:18 pm
Here's a couple of other differences...
PRINT doesn't print those pesky column headers.
PRINT outputs to the MESSAGES tab even if the GRID mode is turned on. SELECT will print to the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2005 at 9:15 pm
Ok, so you've shown what doesn't work... what, in your estimation, would work if you were given that particular problem (the Adam Mechanic one) with that particular data?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2005 at 10:27 pm
Michelle/Dolphin,
Thanks for the feedback on the medical community... I guess that's one place where the following saying (author unknown) applies...
"Normalize 'till it hurts,
DeNormalize 'till it works."
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2005 at 9:06 pm
>The proprietary syntax has unpredictable results.
Only in something other than the SQL it was written in. It is not upredictable in SQL Server.
>Notice that we did not use the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2005 at 8:55 pm
>First option makes optimizer work faster
Sergiy,
Can you show me where this is written? The reason I ask is because I've got a bunch of folks at work that use...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2005 at 6:39 am
Dang... I missed that. Sorry Shahed and thanks for the feedback. Glad you got it working...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2005 at 6:32 am
Roger that... thanks. I'm just the opposite... I leave the aliases just for brevity... I figure that it takes about 2 seconds to figure out that "c" means "Customer". But...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2005 at 2:13 pm
Obviously, I haven't tested this but it should be real close.
UPDATE A
SET Flag = 1
FROM A,
(--Derived table "bd" finds everything in B having a count...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 1, 2005 at 9:35 am
Viewing 15 posts - 58,756 through 58,770 (of 59,076 total)