Viewing 15 posts - 51,511 through 51,525 (of 59,102 total)
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
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
Viewing 15 posts - 51,511 through 51,525 (of 59,102 total)