April 18, 2017 at 10:47 pm
Comments posted to this topic are about the item Package Parts – First Impressions
April 18, 2017 at 10:49 pm
The inability to access package variables renders Package Parts pretty useless, actually.
April 19, 2017 at 6:59 am
it has few shortcomings
--from article
The inability to access package variables renders Package Parts pretty useless, actually
--reader comment
I think you meant to say, it has a few shortcomings. And that is generous. Microsoft has at least recognized the need. But the reader comment hits it exactly--without the ability to use package variables, I can't think of a single practical use for it. If it did work with package variables, I would have lots of uses for it. Hopefully the wait won't be too long.
April 19, 2017 at 7:42 am
The inability to access package variables renders Package Parts pretty useless, actually
I haven't used SSIS for a while but I remember similar behaviour from elder versions (SQL Server 2003). It wasn't possible to assign values to package variables at runtime directly. However it has always been possible to assign values via a script task. I'm convinced that a script task can pass package variables to exposed package part variables.
You should give that a try. If it was possible 10+ year ago, why should it not be possible nowadays?
April 19, 2017 at 8:19 am
from elder versions (SQL Server 2003).
SSIS changed A LOT in the 2005 version. There is no more activeX script. I used to be able to do a lot of things using ActiveX script that I still can't do in VB.Net. In any case, that's quite a leap. You need to be able to access properties to assign values. It might be possible, but it wouldn't be safe to assume that because it was possible in 2003 should mean that it's possible now.
April 19, 2017 at 9:00 am
April 19, 2017 at 9:12 am
There is no more activeX script
That is true. However I (for whatever reason) never used 'ActiveX script task' but the plain 'Script task' with underlying C# code.
Simple exercise:
Create 2 variables of type String: TestSource and TestTarget. Assign a value to TestSource and nothing to TestTarget
Create a 'Script Task' on the package. You need to define read-only and read-write variables on the task properties:
In the C# code('Edit Script' button), you just add this line to your entry point method (default is Main but can be changed on the properties):
Dts.Variables["User::TestTarget"].Value = Dts.Variables["User::TestSource"].Value;
Run the task/package. On exit of the script task, the TestTarget value is the same as TestSource.
You just need to remember to set variable scope correctly.
If variables from package parts can be defined in a package, they can be accessed by package elements so that should work.
April 25, 2017 at 3:47 am
I am trying to understand how Microsoft could introduct something so limited.
ALL our packages are highly parameterised, this includes the database connection details plus a ton of other variables. If there is no way of passing in variables for connections or anything else then for us it is essentially useless.It would have been far better if Microsoft had produced something that was truely usefull instead of something half baked. And it seems to have quite a few issues (errors) as well.
December 5, 2018 at 2:10 pm
Thanks to this post: https://prathy.com/2016/06/my-thoughts-on-ssis-2016-ssis-package-parts-2/ it appears that you can use the Package Parts variables in the Package but you have to manually change the scope of the variables once you pull the PP into the Package.
However, for my organization as well, the separate connection objects are the killer shortcoming. There's no way we're going to manually change the connections on the parts when all the Package connections are being managed/changed via environments on the server.
I'm hoping this will improve in future versions but at the moment what they have out with 2017 is not good enough to be useful.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply