Viewing 15 posts - 56,941 through 56,955 (of 59,067 total)
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
Thanks Farrell,
That's a high compliment coming from folks like yourself.
Vamsi,
On my way to work so can't answer in detail just now but, I need to know, what are the boundaries...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 6, 2007 at 6:25 am
Nicely done, Robert.
I'm still waiting for the original poster to definitely describe the datatype of the column he named "TimeStamp" (instead of guessing
).
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2007 at 7:15 pm
Ok, here's some sample code using Michael's function that I renamed as "fnTally" and changed the "Numbers" column to just an "N" to match what I also have in my...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2007 at 7:09 pm
1) WHERE Name IS NULL - is that specific to your Master.dbo.spt_Values table?
It is specific to the Master.dbo.spt_Values table... however, the table isn't "my" table, it's part of...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2007 at 5:22 pm
Viewing 15 posts - 56,941 through 56,955 (of 59,067 total)