August 3, 2015 at 11:19 pm
Comments posted to this topic are about the item Display SSIS package version on the Control Flow design surface
August 4, 2015 at 5:54 am
Nice article Herman. At the end you say ( see for example) when you are referencing putting the new expression into the error message. But, I do not see what you are referring to. Was that meant to be a link to some other article or attachment? I say that because it is early in the morning and I am not sure off the top of my head how to put that expression into any and all errors that a package might generate, as opposed to putting it into a single step error by explicitly referencing the expression in the specific task's error output.
August 4, 2015 at 9:53 am
Nice Article, But you can see the VersionBuild under Version Property of the package.
Best,
Naseer Ahmad
SQL Server DBA
August 4, 2015 at 10:28 am
This is great! I was able to immediately put it to use, and then made a small adjustment to the implementation to see if it could be done.
I slightly altered the Expression and added it as the Description property of the first SQL Task in my package which logs the start of an EDI/ETL process. The following shows the altered expression. Note that the Description property does allow periods, so I replaced the dash with a period in the Version number.
"Package: "+@[System::PackageName] + " Version: " + (DT_STR,5,1252)@[System::VersionMajor] + "." + (DT_STR,5,1252)@[System::VersionMinor] + " Build: " + (DT_STR,5,1252)@[System::VersionBuild]
Example evaluation: "Package: EZClaim PS Data Version: 1.0 Build: 12"
Now I get the info as a tooltip when I mouse over the task. Not as in-your-face as your example, but it works and the same technique can be applied to other needs.
Thanks for the great tip!
J Pratt
August 7, 2015 at 1:45 am
I am happy you liked the article, use it as it is most suitable for you!
@jpratt nice idea to use a tooltip!
@Naseer of course the version can be found under version property, but you need several mouse clicks to find it. The trick I described displays the version on the designer surface and makes it mulch easier to monitor. Probably I am too lazy to use the property:-)
@knausk When I wrote the articie I expected to be able to a best practices article published by Jamie Tomson in which he describes way to generate error messages and send emails on failure. Unfortunately the article does not exist anymore on the web. Instead I referenced the list of best practices suggested by Jamie. When you are interested I can send you a document I wrote about the way I implemented a SSIS template. It is unfortunately not suitable for publishing as-is. but when there is enough interest I can prepare it.
Let me know if you would be interested in receiving my document
August 7, 2015 at 5:32 am
Herman, I would certainly like to see the article and template.
August 7, 2015 at 8:57 pm
Neat trick! I can see myself using it very soon. Thank you for sharing!
April 28, 2017 at 5:46 am
Despite the fact that this is a neat idea, I can't really see how it solves this situation:
Did one of your colleagues maybe made some corrections yesterday, which did not make it to your VCS? Are you sure?
Having quick visual access to version numbers does not give you insight into what other developers have done outside of your VCS. Or maybe I am missing something?
IMO, production packages should be deployed from the current master branch of your VCS, without exception – and this deployment should be automated to avoid human errors and inconsistencies. If that is in place, none of this is an issue.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply