Viewing 15 posts - 58,906 through 58,920 (of 59,075 total)
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
Perhaps instead of a stored procedure, it should be a view so that you can select from it as if it were a table. Also, take a look at OpenRowSet...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2004 at 8:58 pm
Dude?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 28, 2004 at 9:00 am
Do you want to automatically delete the dupes (leaving only the earliest or the latest) or just find them? Frank is correct... the search leads to lot's of "duplicate row" goodies...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 27, 2004 at 7:24 am
Viewing 15 posts - 58,906 through 58,920 (of 59,075 total)