Viewing 15 posts - 58,891 through 58,905 (of 59,063 total)
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
> Do you think this may pose deadlock problems? This should be the only stored procedure or even script for that matter that would ever access this table.
Fred,
Yeah, your method...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2004 at 6:16 am
A third party company that we had the great misfortune of hiring, did something similar (nearly identical) in our database... it caused an average of 620 deadlocks a day. The...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2004 at 11:56 pm
Not sure why you wouldn't want to use a set based Trigger for this... it's a tried and true method and will run raster than anything else you could throw...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2004 at 11:08 pm
>Will having 2 records for the one shift with 2 seperate ID's affect my Analyisis Services CUBES?
Here's a bit of code where you will not have two records... most of...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2004 at 1:11 am
Viewing 15 posts - 58,891 through 58,905 (of 59,063 total)