Viewing 15 posts - 58,921 through 58,935 (of 59,091 total)
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
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
Viewing 15 posts - 58,921 through 58,935 (of 59,091 total)