Viewing 15 posts - 51,496 through 51,510 (of 59,091 total)
Yep... on the small stuff for sure.
Just a note, though... CPU time makes all the difference in the world to me... most of the 8 hour jobs at work that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 12:24 pm
Matt Miller (3/26/2008)
Hmm - I'm seeing dropped tables....You looking at the right trace? mine seems to automatically roll over after a certain size.
I think so... here's the command I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 12:16 pm
Heh, yeaup... thought I'd let that one go 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 12:13 pm
To put it a bit differently than Matt... INSERT triggers fire only once per INSERT statement no matter if one row or thousands of rows are affected. Same is...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 12:02 pm
Matt Miller (3/26/2008)
At least try a different approach or something....
Not blasting the OP by any means... but sometimes a "different approach" means getting someone that knows how to put the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 11:58 am
Dunno about that, but there sure is in a BCP import. But, I think the DTS route would be better because if you're using text qualifiers in the file,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 11:45 am
Totally awesome find... but despite the DROPS I've done on tables and the like, there's nothing in the log. There is something, however, for someone dropping a database.... gives...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 11:40 am
Ummmm.... you don't really need a CLR or external RegEx to do something so simple as to remove leading zeros. For example...
DECLARE @Sku NVARCHAR(500)
SET @Sku...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2008 at 11:07 am
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
Viewing 15 posts - 51,496 through 51,510 (of 59,091 total)