September 27, 2016 at 3:32 pm
Hello All,
Background, I have newly inherited existing system and project, a SQL Server 2014, with a number of projects, solutions and packages created with VS 2013 DT.
Issue, it was all done under a generic login, all on the server and local C:\, not sharable.
I have copied the files related to a solution to a share drive located on the server, and not the files are in a more shareable location.
Then using the generic login ID I opened each and every file related to this solution, namely .dtsx files.
I changed the encryption off and set to none on all files.
Now I can use my own ID to login, and navigate to the copied modified solution with VS 2015 DT that is installed on my local PC, connected to the server.
When I open the package, get get errors when I first open it, and it seems to be primarily related to the load packages, the main error I get is:
"Microsoft Visual Studio is unable to load this document: Object reference not set to an instance of an object. "
Followed in this solutions case with 14 errors, all reading like this:
SeverityCodeDescriptionProjectFileLineSuppression State
ErrorError loading Load SQL SubDaily Dyn Dims.dtsx: The component metadata for "Teradata Src Device" could not be upgraded to the newer version of the component. The PerformUpgrade method failed.X:\Visual Studio 2013\projects\ABHS_BI_Daily\ABHS_BI_Daily\Load SQL SubDaily Dyn Dims.dtsx1
and
SeverityCodeDescriptionProjectFileLineSuppression State
ErrorError loading Load SQL SubDaily Dyn Dims.dtsx: The managed pipeline component "AttunitySSISTeraSrc.8" could not be loaded. The exception was: Could not load type 'AttunitySSISTeraSrc.8' from assembly 'Microsoft.SqlServer.PipelineHost, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'..X:\Visual Studio 2013\projects\ABHS_BI_Daily\ABHS_BI_Daily\Load SQL SubDaily Dyn Dims.dtsx1
Please let me know what additional details I can share, and please let me know whatelse I can describe as I move files created on one account on the server and now moved and being edited by another account, I'm trying to make all the projects/solutions to be fully shareable and editable by other developers, but remain close to the server to be run on a schduler, and use the utilities of the data connectors, etc...
Many Thanks
September 27, 2016 at 4:50 pm
Have you got the Attunity SSIS Connectors installed on your local PC?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 27, 2016 at 4:54 pm
You should consider making some changes, to open things up and get closer to best (or at least, 'rather good' :-)) practice:
1) Use the project deployment model, to deploy your SSIS packages to SSISDB on the server.
2) Store your packages in a version-control system.
3) Automate the deployment of your packages from the VCS versions.
4) Set the protection level to Don't Save Sensitive throughout.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 27, 2016 at 5:18 pm
Well, whats that, so I'll say no. What can you tell me about them and why I must install, other than to match what may apparently also be on the server.
I have installed to the local machine: SQL Server 2014, Visual Studio 2015 and the SSDT for 2015.
September 27, 2016 at 5:20 pm
quinn.jay (9/27/2016)
Well, whats that, so I'll say no. What can you tell me about them and why I must install, other than to match what may apparently also be on the server.I have installed to the local machine: SQL Server 2014, Visual Studio 2015 and the SSDT for 2015.
I should add, that most of the packages are connecting to Teradata, and working with it as a source and in come cases target.
September 27, 2016 at 5:23 pm
The error messages mention Teradata and Attunity, so I am assuming that the packages have one or more connections to a Teradata database.
Such connections are not natively supported in SSIS – you'll need to install something like this.
And please note that I have never connected to a Teradata database in my life, so don't be too reliant on what I am saying!
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 27, 2016 at 5:24 pm
Phil Parkin (9/27/2016)
You should consider making some changes, to open things up and get closer to best (or at least, 'rather good' :-)) practice:1) Use the project deployment model, to deploy your SSIS packages to SSISDB on the server.
2) Store your packages in a version-control system.
3) Automate the deployment of your packages from the VCS versions.
4) Set the protection level to Don't Save Sensitive throughout.
1, I'll look into that
2, that's an excellent idea, and I'll find something for that, should make life easier for all
3, can you please elaborate on this, whats VCS, and why automate the deployment
4, I have had to manually change this in a test copy of a set of solution files from a sample project, really testing to see if that was one of the items presenting an issue, it was. Are you saying to make a change at a more global level? There are so many packages that have been built already, not sure how I can make a global change to the existing files/work.
Thanks for the great feedback
September 27, 2016 at 5:43 pm
quinn.jay (9/27/2016)
Phil Parkin (9/27/2016)
You should consider making some changes, to open things up and get closer to best (or at least, 'rather good' :-)) practice:1) Use the project deployment model, to deploy your SSIS packages to SSISDB on the server.
2) Store your packages in a version-control system.
3) Automate the deployment of your packages from the VCS versions.
4) Set the protection level to Don't Save Sensitive throughout.
1, I'll look into that
2, that's an excellent idea, and I'll find something for that, should make life easier for all
3, can you please elaborate on this, whats VCS, and why automate the deployment
4, I have had to manually change this in a test copy of a set of solution files from a sample project, really testing to see if that was one of the items presenting an issue, it was. Are you saying to make a change at a more global level? There are so many packages that have been built already, not sure how I can make a global change to the existing files/work.
Thanks for the great feedback
3) VCS = Version Control System
Automating the deployment does a few things:
a) Takes away the likelihood of human error ... always does it right, or at least, the same.
b) Deploying from a VCS means that you always know exactly what is deployed.
c) Deploying SSIS projects at the click of a button means that you can spend your time doing something more productive.
4) Making a global change to protection level is one of the most boring tasks in SSIS (right up there alongside manually creating 100 output columns). I have found no alternative to opening the package, changing the property, and saving.
But perhaps you can make a strategic decision right now that all new development will be done this way. And gradually move the others over. Sensitive parameterised information (eg, passwords) should be stored as sensitive variables in SSISDB environments. Your projects can be configured to take the values of these parameters when they are executed.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 27, 2016 at 8:28 pm
Phil Parkin (9/27/2016)
The error messages mention Teradata and Attunity, so I am assuming that the packages have one or more connections to a Teradata database.Such connections are not natively supported in SSIS – you'll need to install something like this.
And please note that I have never connected to a Teradata database in my life, so don't be too reliant on what I am saying!
Ok, I understand now. I can do this, however, my concern is that I want to move the existing solutions to a shared dir on the same server, but connect to that server from my desktop, where they were previously connecting to it with Remote Desktop. I still want all the solutions/packages on the server to run on there, and be dependent on all the utilities, like connecters and loaders, that are on that server. Will installing Attunity on my local blow that up? Also, the retooling exercise, is to also make these locked up solutions/packages to be used by other developers on the team, who will also be connecting to the server from their local installs on their desktop, but also the occasional user who will still login with the generic ID and straight in with Remote Desktop. I'm concerned with introducing a dependency in a package that is lost on another user and their setup.
September 28, 2016 at 5:56 am
quinn.jay (9/27/2016)
Phil Parkin (9/27/2016)
The error messages mention Teradata and Attunity, so I am assuming that the packages have one or more connections to a Teradata database.Such connections are not natively supported in SSIS – you'll need to install something like this.
And please note that I have never connected to a Teradata database in my life, so don't be too reliant on what I am saying!
Ok, I understand now. I can do this, however, my concern is that I want to move the existing solutions to a shared dir on the same server, but connect to that server from my desktop, where they were previously connecting to it with Remote Desktop. I still want all the solutions/packages on the server to run on there, and be dependent on all the utilities, like connecters and loaders, that are on that server. Will installing Attunity on my local blow that up? Also, the retooling exercise, is to also make these locked up solutions/packages to be used by other developers on the team, who will also be connecting to the server from their local installs on their desktop, but also the occasional user who will still login with the generic ID and straight in with Remote Desktop. I'm concerned with introducing a dependency in a package that is lost on another user and their setup.
If you want to get away from RDP sessions, and have developers working locally, the developers need to have the connectors (and any other non-standard components) installed on their machines. You are not 'introducing dependencies' ... the dependency was already there as a result of the design of the package.
I want to move the existing solutions to a shared dir on the same server, but connect to that server from my desktop
Can I just confirm that you are referring to a development environment here, and not a production server?
Excuse my frankness, but if this is a production server, this is a terrible idea. You seem to be suggesting having a single set of packages on a server, editable by multiple developers, with no source control – am I correct? Really, don't do this.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 28, 2016 at 6:13 am
I want to move the existing solutions to a shared dir on the same server, but connect to that server from my desktop
Can I just confirm that you are referring to a development environment here, and not a production server?
Excuse my frankness, but if this is a production server, this is a terrible idea. You seem to be suggesting having a single set of packages on a server, editable by multiple developers, with no source control – am I correct? Really, don't do this.
[/quote]
There is a lot to say, and hard to answer, however this is why in part I'm trying to get the developers to run locally, so dev and test in a sandbox before moving to a prod environment. I'm going to PM you now.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply