TheViewMaster wrote:
By default Import/Export wizard tries to save all records in 1 transaction - BUT saving 40 million rows in 1 shot (even in simple recovery model) is STUPID STUPID STUPID
Perhaps another way to look at this is in the context of "reasonable defaults." I would not expect the default import/export size to be 40 M rows, so I personally do not think that the package created by default should need to handle this data volume without some sort of review or modification.
Still, it would not hurt to have an "Advanced Options" (or whatever - pick your name) page in the wizard that asked data size and volume questions, and set some of these properties more intelligently based on this input.
MatthewRoche wrote:
Still, it would not hurt to have an "Advanced Options" (or whatever - pick your name) page in the wizard that asked data size and volume questions, and set some of these properties more intelligently based on this input.
Phil Brammer wrote:
MatthewRoche wrote:
Still, it would not hurt to have an "Advanced Options" (or whatever - pick your name) page in the wizard that asked data size and volume questions, and set some of these properties more intelligently based on this input.
This is a good idea. Either yourself or TheViewMaster should post a Connect feedback item requesting this feature to be added.
Posted: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx FeedbackID=278281
Odd that there is no SSIS category available...
I'm having a heck of a time converting a very simple text file import dts package (takes 2 minutes to create the whole thing in dts). Initially, I had the same problem as you - couldn't get the date columns to work no matter what I tried. Finally I changed the destination columns to strings (now I'll see if I can convert the strings in that table to another table with the proper 'date' data type.
I'm also having trouble with the thing telling me it can't import a column (from the same file) because of potential data loss (I've tried real, float, numeric types). The source data is not that large (less than 10,000,000.00).
I 've been a huge fan of Microsoft, SQL Server (especially dts) since SS 7.0. So far, this is the worst software product I've ever encountered.
jw6587 wrote:
I'm having a heck of a time converting a very simple text file import dts package (takes 2 minutes to create the whole thing in dts). Initially, I had the same problem as you - couldn't get the date columns to work no matter what I tried. Finally I changed the destination columns to strings (now I'll see if I can convert the strings in that table to another table with the proper 'date' data type.
I'm also having trouble with the thing telling me it can't import a column (from the same file) because of potential data loss (I've tried real, float, numeric types). The source data is not that large (less than 10,000,000.00).
I 've been a huge fan of Microsoft, SQL Server (especially dts) since SS 7.0. So far, this is the worst software product I've ever encountered.
Wow.
I certainly cannot argue with your experience, but for me the opposite was true. For me, DTS was practically impossible to work with for anything but the most trivial uses. My standard line when speaking on BI topics is that would prefer to chew off my own mouse finger rather than work with DTS on a project. SSIS certainly has its faults (and upgeading DTS packages is definitely not one of its strengths), but for data warehousing and other real-world ETL purposes it is light-years ahead of DTS.
MatthewRoche wrote:
Posted: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx FeedbackID=278281
Odd that there is no SSIS category available...
Phil Brammer wrote:
MatthewRoche wrote:
Posted: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx FeedbackID=278281
Odd that there is no SSIS category available...
There is... Sort of. It's DTS.
Can you edit the posting and change it to DTS
Thanks,
Phil
Apparently not. The only field that I can edit is the private/public flag.
MatthewRoche wrote:
Apparently not. The only field that I can edit is the private/public flag.
TheViewMaster wrote:
So what are your thoughts about trimming down SSIS to just importing everything as text to database
My thoughts are its a stupid idea.