March 20, 2007 at 6:59 am
Hi Gail,
I have a VB script that computes a global variable date that is used as a parameter in several Transform Data Tasks. These tasks go into in another SQL Server (2000) and pull data across to my datamart. It works fine on my 2000 production server. In Version 2005, the global variable is not being placed in the parameterized Transform Data Tasks correctly resulting in a "missing parameter errors".
When attempting to fix the error by editing a DTS job in 2005 SQL Server Management Studio, you must first convert the DTS job to full blown SSIS. The graphic representation of the DTS job from 2000 is hammered in 2005. The way the Transform Data Tasks are represented is completely different...they are handled in separate tabs in SSIS relative to the overall process flow (On Success/On Failure/On Completion). This entire user interface is new and must be re-learned before the production database can be moved.
It will likely take months to convert all of our production DTS packages from 2000 to 2005 before we migrate the production databases to the new server.
March 20, 2007 at 7:10 am
Don't know about the global parameters, I don't think we use them. Our DTS packages are mainly complex data flows.
What we decided to do was to ensure that the people who develop the DTS packages keep sql 2000 on their machines, hence providing a place to edit the DTS. Nasty, yes, but it works, and it means we can migrate the packages to SSIS at our leasure, not when forced by bugs.
I don't expect we'll finish the DTS-SSIS migration for at least a year after the 2005 upgrade.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 7, 2007 at 12:13 pm
This is my biggest problem with 2005. They took an extremely intuitive product (DTS), and Microsoftized it. By that I mean they added a boatload of features (most of which I don't need), and decreased the usability by many orders of magnitude. Microsoft has lost sight of the fact that database developers need their tools to be efficient and easy-to-use. Just because we are generally smart people who have worked in IT for a while doesn't mean we want a cluttered product with 50 million features. There are a subset of Microsoft diciples out there who have the philsophy that "more features"="better product". In the real working world though, DBAs and Database Developers need efficient tools that make the common task easy. SSIS makes the common task hair-pullingly difficult.
Try moving data from a text file to a database table in SSIS. Take many, many more steps that doing the same task in DTS. To execute the package, one must apparently always start the "Debugging" mode. I don't always want things to run in debugging mode, especially since the error messages are generally not useful.
Mapping data from a text file to a database table is its own little adventure in SSIS. Now, we must know the data type of the source text file. How often does someone give you a tab-delimited text file WITH a datatype for each column? And, on top of that, Microsoft introduced yet another collection of datatypes specific to SSIS. So, when mapping your data in the source text file to a SQL Server table, you have to figure out the equivalent to numeric or bigint. These are not enhancements, these are nonsensical changes designed by someone who made no attempt to consider usability and productivity.
I'm very concerned about the direction Micosoft is taking this product. They are simply not using feedback from people who use these products all day.
May 7, 2007 at 12:22 pm
I feel your pain I really do. I agree with what you stated. I have ALWAYS stated the SQL Server 2000 was by FAR the easiest to use vs. Oracle and DB2 hands down. With 2005 it appears they now are moving in the direction of complicating us DBA's with complicated more clicks to do the same thing in 2000. Some features are almost gone. I have to say I am not actively pushing to upgrade ANY of our SQL Servers to 2005. I hear rumblings that the next version of SQL Server might be out by the end of next year possibly.... if that is the case why kill myself implementing a more difficult to use product that will be obsoleted in 18 months possibly... PLUS spend the 250K in licensing for all of our SQL Servers to simply go back and say... we are obsolete in just over a year....
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply