Home Forums Data Warehousing Integration Services Open Solution Created in VS2013 with VS2015, SSIS Load Package Errors RE: Open Solution Created in VS2013 with VS2015, SSIS Load Package Errors

  • 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.

    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.