Viewing 15 posts - 51,511 through 51,525 (of 59,098 total)
Even if you are - shouldn't you be keeping the audit trail of the updates to said stored procedure? You know, as in Source control? I kind of...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 8:37 am
SMO would just slow you down and I don't think you need real dynamic SQL.
Why can't you just populate a table with the Old/New values and do a simple joined...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 8:19 am
Sure, I get the same on the small test... times for the outer join vary between 16 ms and 67 ms with the norm being 47 ms... but look at...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 8:16 am
Matt Miller (3/26/2008)
Jeff - George has inherited one of your long-term Nemeses as a problem ("manual" identity fields, and yes, used RBAR).
How do you know that, Matt? Shoot, that's...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 8:07 am
Matt Miller (3/26/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 8:00 am
Wasn't your fault... the "other" person started it that way.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:57 am
One way to find the bad row is to import it into a two column table (1 for a row num, the other for the data). You know how...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:54 am
If nothing has changed on the system, then keep looking in the source file... the problem is there and you've just not seen it yet. My favorite error is...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:51 am
If it's for "point in time", then I'm pretty sure you need FUll Recovery and differential backups multiple times per day. Do 1 full backup a week... differential backups...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:45 am
Balmukund Lakhani (3/26/2008)
Default trace would help you in such cases if you are on SQL 2005. very few knows the power of it.
Heh... don't tease us, now. Would you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:41 am
I agree with Michael Earl... I've done this many, many times (cofiguration table that looks like a name/value or "EAV" table). I've found that it's very handy. When...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:38 am
Not real sure it'll increase performance because CASE statements in the SELECT list are normally pretty fast... BUT, things like the following...
case when @nPlatformAssets = 0 then...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:33 am
George Heinrich (3/26/2008)
what I really want to know is how can you run a SP with multiple instances without getting a deadlock?
There is... unfortunately, it requires a rewrite of...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 7:19 am
krishrana17 (3/26/2008)
but can u explain me what is the benefit of timestamp column??
About the only thing it's good for is to let you know that something has changed. Each...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 6:37 am
I've never had a problem with the backups staying in synch... that's what the "Archive" bit is for. But, yes, I can see where that could cause problems for...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 5:57 am
Viewing 15 posts - 51,511 through 51,525 (of 59,098 total)