Viewing 15 posts - 56,791 through 56,805 (of 59,069 total)
Putting the Recovery Mode to Simple sets the 'trunc. log on chkpt.' to true automatically. Your problem is the log... your Insert/Select is still logged despite the SIMPLE setting you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:53 pm
p.p.s. Why the hell are you using DTS for such a simple BULK INSERT task, anyway... you like "slow" or something ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:42 pm
Yeah... me too... sorry you had to wait 4 years for the answer... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:40 pm
I agree... NOT EXISTS implies a correlated sub-query which is another form of RBAR (pronounced "ree-bar" and is a "Modenism" for "Row By Agonizing Row").
Now, the interesting part is that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:39 pm
Another way... with right justification to boot...
SELECT STR(COUNT(DateCol)/110.0*100.0,8,1)+'%'
FROM @Table
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:32 pm
P.S. It won't blow up after 6,759,999... but it will start the sequence over, so you may want to put a constraint on the IDENTITY column to be >=0 and...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:14 pm
Ummm beat me to it... well, almost... please send beer, I already have enough pretzels...
--===== If the demo table exists, drop it
IF OBJECT_ID('TempDB..#yourtable') IS NOT NULL
DROP...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 7:09 pm
TNT,
Just for grins, can you post the "header file" and a row or 2 of data (making sure, of course, there are no SSN's, account numbers, etc in the file)? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 6:09 pm
Sure, Bakr... but I need a wee bit more information...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 6:01 pm
Perfectly clear, thank you...
DECLARE @TestData TABLE (StringValue VARCHAR(20))
INSERT INTO @TestData
SELECT '0000022211' UNION ALL
SELECT '0000022243' UNION ALL
SELECT '0000072211' UNION ALL
SELECT '0000102221' UNION ALL
SELECT 'AB00011' UNION ALL
SELECT 'CD000111'
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 4:20 pm
What did you find out about memory? Do you have an app that someone recently made a change to that has memory leaks?
Also, since it occurs so regularly, have you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 6:58 am
Heh...
Dinesh... take a look at the following for a complete explanation as to why ISNUMERIC should never be treated as ISALLDIGITS... and, it's not a fault... it's a feature...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 12, 2007 at 6:41 am
Please folks... make sure you really, really know what you're doing... if you set 'trunc. log on chkpt.' to true, you have a little surprise coming... try this...
Set the recovery...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2007 at 9:48 pm
Do you mean like this when you say to "ignore if is character data"???
DECLARE @t TABLE( sort varchar(20))
INSERT INTO @t
SELECT '1dd' UNION ALL
SELECT '1x4' UNION...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2007 at 9:36 pm
Sree,
Rather than us guess, do you have some samples of the data before and after the sort you'd like?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 11, 2007 at 7:21 pm
Viewing 15 posts - 56,791 through 56,805 (of 59,069 total)