Viewing 15 posts - 51,331 through 51,345 (of 59,102 total)
BULK INSERT is absolutely the fastest... but I don't believe that it supports importing Excel Spreadsheets.
Even if it did, if someone has the spreadsheet open, SQL Server will not...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 10:12 pm
Antonio...
When you say ".RDL", are you talking about a "CLR"?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 10:11 pm
This is actually very similar to the classic "paging problem"... I'll see if I can whip up an example tomorrow (today actually... it's after midnight here) ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 10:08 pm
lalonacademy,
I'm not sure how you got the data into the table, but consider this... BULK INSERT with a format file to handle your strange delimiters will load 5.1 MILLION 20...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 10:00 pm
Ok... here's my entry for the virtual beer...
1 million rows... half are the first row and half are the second row that the Op posted. My goal was to...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 9:56 pm
Thanks guys... I knew it had to be something simple :blush:
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 9:20 pm
antonio.collins (4/1/2008)
sounds like a challenge to me! winner buys a round of beer for everyone?
Sure, I'm good for a virtual beer and pretzels... Million rows ok with you? 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 7:37 pm
lalonacademy (4/1/2008)
I have a text (words separated by the symbol '&' (symbol ampersand). I need...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 7:36 pm
Heh... I love it... someone gave me the ultra low mark of 1 star and didn't even have the nerve to tell me why.
Would it help if I told you...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 7:26 pm
Thanks, Antonio...
While I agree that the XML concatenation method is very fast, I've found that the XLM parsing method is a bit slow compared to a Tally Table or cteTally...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 6:59 pm
Just checking to be sure... do all the rows have exactly the same number of "fields" and all the rows are always in the same basic format?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 6:44 pm
Gosh, I hate the idea of replacing one form of recursion with another, but the recursive CTE will at least handle a set even if it is hidden RBAR.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 4:50 pm
GSquared (4/1/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 4:44 pm
Heh... you can tell I've watched way too many info-mercials! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 4:29 pm
Harveysburger (4/1/2008)
Would this affect anyone's conclusion on the design?
No... disparate transaction types should live in their own tables. Rules of normalization such as no duplicates and no nulls should...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2008 at 4:13 pm
Viewing 15 posts - 51,331 through 51,345 (of 59,102 total)