Uniquely Identify a SSIS Package within that Package

Question

Uniquely Identify a SSIS Package within that Package

SQL STEWIE

SSCommitted

Points: 1837
More actions
March 30, 2010 at 7:58 am

#222570

I am sure that what I want to accomplish is not do-able, but I figured I would ask.
I have an SSIS that will have the same name, but will reside on the same server within several different folders. I know the unique way to identify a package within the sysdtspackages90 folder is via the name, folderid columns. However, what I need to do is be able to know within the SSIS package, that the one running matches up to the right folder. For example:
I have SSISTest package that lives in folder1 and folder6. When SSISTest executes in folder1, I need the package to know that it is the folder1 copy running, and not the folder6 copy.
The reason for this is because I am creating a logging and error handling application, and want to make sure that the information getting logged by SSISTest in folder1 matches up with the SSISTest in folder1 ID in my custom application.
Does anyone know what I can do? I have been researching (and will continue to) but have not found anything. If more clarification is needed, I will try my best!
Thanks!
Michael

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 1

I'm still a little fuzzy on the WHY? I think having the same package in multiple places is generally a bad idea, and there are very few (IMO) business or technical reasons to do this.

Also, I am not aware of anyway for it to know which folder it was run out of. I couldn't find any variables that provide that. There is a limited possibility that a script task MIGHT be able to, but I am still stuck with the WHY.

I really think we should review what exactly you are trying to accomplish because I'm 99.9999% sure there is a better way.

CEWII

SQL STEWIE SSCommitted Points: 1837 More actions · Answer 2

I agree 150% that there is a better way to store and manage these packages....but I am inheriting an existing setup in which is would be VERY difficult to go back and change package names, etc, mostly because of the dependendices on those jobs.

Thanks for checking though, I do appreciate it! 🙂

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 3

Unfortunately, sometimes when we inherit something stupid we have to just suck it up. Other times we can push back and say this is virtually unmanageable and needs to be revisited. I'm wondering if this is one of that later..

CEWII