Viewing 15 posts - 58,891 through 58,905 (of 59,067 total)
Karen,
Bob and I both made the same boo-boo... in the code where the fields get added up, you must include all of that addition in parentheses or you'll get the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2004 at 6:05 am
There's many ways to do this but most will involve a loop or a (yeeeeech!) Cursor (Haaaaaack... Patooooooiiiii!), a temp table, or maybe some extra columns added to your existing...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 11:17 pm
Beryl,
Borrowing on Kathi's idea, this may run a bit faster because it does no string manipulation or conversion and only has one comparson operator (=). And it could easily be...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 10:10 pm
I agree that dependencies related tables are (more or less) unreliable but the SYSOBJECTS and SYSCOMMENTS tables are always up to date with the latest code for any given object. The...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 6:39 am
You may want to avoid using the guest account for several reasons... here's what the MSDN link that yoav provided warns of...
"Avoid using the guest account; all logins without their...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 6:24 am
>Colleague put a trigger on the table that was causing the error.
Paully21,
There may be a much larger problem lurking in the shadows of that trigger you found... many folks write...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 6:13 am
This code also works... Like the code that Kenneth posted, you should be made aware that if the, say, stored procedure is longer the 8k bytes and the table name...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 6:02 am
You bet, Gazley... BOL tells you EVERYTHING and sometimes it's much more than you need (although, I always start there) or can be difficult to draw a conclusion from. It...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 5:45 am
John,
SCOPE_IDENTITY() does require the use of parentheses like GETDATE() does. I didn't see them in the code you posted and I'm hoping that was the only problem you had.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 4:54 am
Gazley,
The reason I said that using @@IDENTITY in the presence of triggers is "Death by SQL" is because of the way @@IDENTITY works... it (basically) returns the IDENTITY of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2004 at 4:50 am
Like I said, Joe... all of your explanations are spot on and I agree with telling folks of the dangers that lurk out there... but there's two ways to tell...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2004 at 9:06 am
Dang, Joe... lighten up! All of your suggestions are spot on but you have to remember that, sometimes, it's a third party database that these folks have to deal with...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2004 at 1:33 am
Then you already know that using @@IDENTITY in the presence of triggers is "death by SQL" and that the use of "it" is hardly ever the "best way" (as Ken was...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2004 at 12:26 am
Thanks nskr72... I missed that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2004 at 7:10 am
You can avoid this...
IF (@FromDate = NULL)
SET @FromDate = '1/1/1900'
... by doing this... (just a bit faster, I think)
SET @FromDate...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2004 at 9:34 pm
Viewing 15 posts - 58,891 through 58,905 (of 59,067 total)