Viewing 15 posts - 56,971 through 56,985 (of 59,101 total)
Cool... Thanks for the info, Robert. I never tested to see if a trigger fired on a zero row insert... they way I write most of my triggers, it probably...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 5:31 pm
Guess you were the straw that broke the proverbial Camel's back this morning... have been fighting with some really stupid requirements written by some really stupid System's Analysts for one...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 8:29 am
Horse feathers... asking "WHY" is very often the key to understanding the problem well enough to help you do what you need.
Since I can't ask "WHY" you want to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 6:54 am
Yep, I agree with Serqiy about the denormalized thing... this is the wrong kind of update... and, if doing the concatenation in SELECTs turns out to be a chore, just add...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 6:35 am
Dunno about Juan, but some folks can be pretty tough on even unrelated code. Lookup some of Celko's replies for an example of what I mean... the intentions are good...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 6:32 am
Doh! I missed that part of the question. Yes, Ron is correct but do remember what I said... It's session specific from SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2007 at 6:29 am
Thanks for posting your own solution... Lordy, I hope someone comes up with a different way... I really have bad gut feeling about updating system tables...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 9:35 pm
Not only do what SQLBill suggested, but why 23 indexes? And, are any of them clustered? Are any of them affected by the update?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 9:33 pm
That should work but I haven't tried it that way...
And, yep, the code I posted up to the "AS" was from Books OnLine... the rest is from some code...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 4:13 pm
PATH is session specific... and each use of xp_CmdShell creates a new session. The only way to do this is to make sure that whatever code you are running contains...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 7:37 am
Yep... that would be correct and that would also be why most folks think it doesn't work in the trigger as capturing the number of rows inserted, updated, or deleted...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 7:14 am
Perfect... using the same function I used previously, adding quarter to this is easy...
DECLARE @StartDate DATETIME
DECLARE @EndDate DATETIME
DECLARE @Days INT
DECLARE @BinSize INT
SET @StartDate = '01/01/2006'...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2007 at 6:56 am
I do it the same way that Lowell and Michael do to maintain the ability to use indexes if one exists. The only difference is, I don't trust users even...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 6, 2007 at 10:08 pm
Juan,
Post your trigger code... we're only guessing until we see the code...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 6, 2007 at 9:47 pm
Not true in a trigger folks... if @@ROWCOUNT is either the very first thing or the first thing after variable declarations, it will identify if any rows have been affected.
The...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 6, 2007 at 9:47 pm
Viewing 15 posts - 56,971 through 56,985 (of 59,101 total)