Welcome to blogs.conchango.com Sign in | Join | Help

Welcome to blogs.conchango.com

SSIS Junkie

SSIS: What do we want in the next version?

SQL Server Integration Services is now, apparently, feature complete. Given that that is the case I started to ponder what would be nice to have in the next version and came up with a list of 30 or so things. I prioritised them and below are what I consider to be my 15 must-haves for the next version. They are all requests for new or modified functionality rather than simply aesthetic changes (apart from maybe #12 & #13).

Do you agree or disagree? Let me know in the comments section below!

  1. The ability to build libraries of data flows, pre-configured tasks and pre-configured transformations that can be instantiated in new packages. I have previously commented on this here.
  2. Ability to alter pipeline metadata at runtime thereby allowing us to build generic file-loading packages
  3. Crossjoin component
  4. Updates using the OLE DB Command component are too slow becaue they do row-based rather than set-based updates! James Howey from the SSIS dev team suggested a new SQL Server specific destination adapter that only does updates. In his own words: "it would seem worthy of investigation to consider an Update SQL Server Destination adapter, which creates a temp table at preexecute, fills it during execution, then issues the Update command postexecute." Couldn't agree more James!
  5. Prioritised destinations - If I have 2 destinations in a data-flow I may want to insist that one is populated before the other, perhaps if the second table has a FK to the first one (N.B. You can do this in Informatica)
  6. Data viewers currently only allow you to view the data in a path. What would be great is if we could issue SQL queries against the contents of the data viewers in order to further interrogate the data and uncover problems.
  7. Darren Green suggested that similar functionality could behave like a conditional breakpoint - break and show the data in the data viewer if my query/boolean expression is satisfied.  Further adapting this idea, you could choose to only display the data viewer if the condition is met.
  8. Option on Auto-layout to have the graph laid out horizontally or vertically. Currently it is vertically only!
  9. Ability to UNDO an Auto-Layout because the results are sometimes worse than what you started with. In fact CTRL-Z on just about anything would be great.
  10. Ability to write variable values back out to a configuration file. I have blogged about this previously here and have included a scenario where it would be useful.
  11. Real-time monitoring tool for deployed packages
  12. Intellisense on expressions
  13. Colour coding of expressions - e.g. keywords highlighted in a different colour
  14. The ability to change a flatfile connection manager to a multifile connection manager (and vica versa), therefore keeping the configuration already applied.
  15. Ability to reference variables in a parent package without having to do it using a script task (a bit more information here).

Care to wager which (if any) of these will make it in? I know Donald already has a long list of ideas for the next version - I wonder if any of these are on it?

-Jamie

 

Published 09 May 2005 14:40 by jamie.thomson

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

TrackBack said:

May 16, 2005 22:59
 

TrackBack said:

May 16, 2005 23:07
 

jamie.thomson said:

Not quite sure if we can use C# and VB.NET inside the SSIS ActixeX Script. Are there any limitations.
May 18, 2005 03:22
 

jamie.thomson said:

PP,
neither C# nor VB/Net are available in the SSIS ActiveX Script task - this only takes VBScript, same as in DTS.

Perhaps you are referring to the SSIS Script task which provides similar functionality. This uses VB.Net exclusively. It does not support C#. There have been alot of discussions about this - many people are unhappy that C# is not supported. Microsoft's answer is that they were under time limitations therefore only support VB.Net in the current version. They plan to support C# in the next version.

Thanks for your comment.

-Jamie
May 18, 2005 14:44
 

jamie.thomson said:

I wish to see a feature like "commit data" as an example, In my data flow lets say I have two destination tables and if there is a failure in execution then to I want to commit the datas in one table and not in the other

Is it possible now? if it is not this can be a feature
May 18, 2005 20:51
 

Jamie Thomson - Life, the universe and SSIS! said:

Planning for Katmai (the next version of SQL Server) is well underway. Integration Services is still...
February 20, 2006 13:14
 

Jamie Thomson - Life, the universe and SSIS! said:

Planning for Katmai (the next version of SQL Server) is well underway. Integration Services is still...
February 20, 2006 13:27
 

Jamie Thomson - Life, the universe and SSIS! said:

Planning for Katmai (the next version of SQL Server) is well underway. Integration Services is still...
February 23, 2006 10:26
 

SSIS Junkie said:

The next version of SQL Server (codenamed katmai) is currently in the planning stages so if you want

January 16, 2007 18:00
 

SSIS Junkie said:

Planning for Katmai (the next version of SQL Server) is well underway. Integration Services is still

January 16, 2007 18:11
 

stan said:

Jamie...I'm just a novice

but i'd like to see...

1) a variable of type "Raw Data" so that if we choose to pass this format

from a master pkg to a sub pkg, i/o isnt required

2) a feature that if chosen, converts a standard but configured task

originally pulled from the toolkit into a custom task for reusability

January 17, 2007 19:26
 

Todd said:

For your point number 5. Prioritised Destinations. Manual control would be useful, but if would be even better if SSIS could read the relationships and automatically set dependencies. In control flow, the automatically placed dependancies could be displayed with a dotted control flow line, which means is could automatically change with the database. The user could right click the line and click Permanent to indicate that it must hold regardless of backend changes.

Also, when designing SSIS packages in VS 2005, the display always get's stuffed up. Zooming out then in fixes it up when it stuffs up. But this shouldn't happen in the first place. It would be nice to have this fixed. I'm not sure if i'm the only one who experiences this, but I tend to see it more in big packages with lots of tasks in the control flow (requiring me to scroll around to view different tasks)

March 28, 2007 02:42
 

jamie.thomson said:

Stan,

Your second comment there is exactly what I refer to in #1 above. I just stated it a different way.

Todd,

I'm not sure I would like the SSIS Designer to automatically do things on our behalf - one of the improvements in SSIS over DTS is that it makes you, the developer, responsible for everythig in the package. Nothing is done implicitly.

However, I certainly like the idea of *suggesting* dependencies like this.

-Jamie

March 28, 2007 04:21
 

Tim McCurdy said:

I'd really LOVE to see them just cleanup their Namespaces in Microsoft.SqlServer.Dts!  Currently, when you go to design a component, you have all kinds of namespace / class conflicts because classes with the same name exist in different namespaces (which you need them in your "using / Imports" statements or your stuck typing huge class names!  I'm tired of this crap response that it was too late in the game to change things!  Hello?  That's the point of .NET!  They can "wrap" their COM Dlls by making them easier to use, I do this all the time when I write .NET wrappers around COM or API.  They should just cut their loses in the next version and start a new namespace "Microsoft.SSIS" and keep it simple.

I'd also love to see "Loop-Backs".  This would be for DataFlows mostly but possibly the Package level too.  For example, I'd like to be able to have a Source, whatever Transforms, and a Destination that saves the data.  Once that data has gone through the destination, it will contain all the new Identity values.  Now, I should be able to drag the "Output" from the Destination BACK to a previous Transform or maybe another destination.  I've run across several situations where Loop-backs would be the perfect solution, however, instead I end up copying a previous Transform with all the same logic in it, and having to paste it as a new one.  This makes Packages HUGE when you have to use the same Script Component 2 - 3 times...

July 9, 2007 15:29
 

jamie.thomson said:

A couple of great suggestions there Tim. Not sure Iagree with the 'loopback' one but each to their own :)

Have you requested at connect.microsoft.com?

-Jamie

July 9, 2007 16:28

Leave a Comment

(required) 
(optional)
(required) 
Submit

This Blog

Syndication

Powered by Community Server (Personal Edition), by Telligent Systems