January 30, 2017 at 11:00 am
Just in case you aren't aware the Target Server Version is used by the script task to know what assemblies to call. The fact this was set to 2016 and worked locally but not on the server (with the error being can't find assembly) leads me to think this is the issue. (Plus I've seen it before).
Usually changing it and rebuilding the project again fixes it but I have seen cases where the script tasks need to be deleted / re-added and the code copied over.
January 30, 2017 at 11:01 am
FridayNightGiant - Monday, January 30, 2017 11:00 AMJust in case you aren't aware the Target Server Version is used by the script task to know what assemblies to call. The fact this was set to 2016 and worked locally but not on the server (with the error being can't find assembly) leads me to think this is the issue. (Plus I've seen it before).
Usually changing it and rebuilding the project again fixes it but I have seen cases where the script tasks need to be deleted / re-added and the code copied over.
Would you advise starting from scratch and setting this before I get started?
January 30, 2017 at 11:07 am
Joe Zonum - Monday, January 30, 2017 11:01 AMFridayNightGiant - Monday, January 30, 2017 11:00 AMJust in case you aren't aware the Target Server Version is used by the script task to know what assemblies to call. The fact this was set to 2016 and worked locally but not on the server (with the error being can't find assembly) leads me to think this is the issue. (Plus I've seen it before).
Usually changing it and rebuilding the project again fixes it but I have seen cases where the script tasks need to be deleted / re-added and the code copied over.Would you advise starting from scratch and setting this before I get started?
You should always set that property at the start of every project before adding anything. I'm surprised though that a rebuild didn't fix it. Did you right click on the project in the Solution Explorer and select rebuild? How many script tasks do you have?
January 30, 2017 at 11:13 am
FridayNightGiant - Monday, January 30, 2017 11:07 AMJoe Zonum - Monday, January 30, 2017 11:01 AMFridayNightGiant - Monday, January 30, 2017 11:00 AMJust in case you aren't aware the Target Server Version is used by the script task to know what assemblies to call. The fact this was set to 2016 and worked locally but not on the server (with the error being can't find assembly) leads me to think this is the issue. (Plus I've seen it before).
Usually changing it and rebuilding the project again fixes it but I have seen cases where the script tasks need to be deleted / re-added and the code copied over.Would you advise starting from scratch and setting this before I get started?
You should always set that property at the start of every project before adding anything. I'm surprised though that a rebuild didn't fix it. Did you right click on the project in the Solution Explorer and select rebuild? How many script tasks do you have?
I have 3 Scripted tasks.
January 30, 2017 at 11:20 am
bmg002 - Monday, January 30, 2017 10:20 AMWhat happens if you try to import the DTSX package to the server via SSMS instead of pushing it from Visual Studio?
I was able to import the .DTSX via SSMS.
I got around the access denied by using
XXX.mssqltips.com/sqlservertip/3086/how-to-resolve-ssis-access-denied-error-in-sql-server-management-studio/
It's for SQL 2008 but it still applies for 2012
January 30, 2017 at 11:34 am
Joe Zonum - Monday, January 30, 2017 10:39 AMBMG002 - I am using a shared folder and have the paths listed as (\\ServerName\SharedFolder)
The share exist on a different server (the App server)I am given the option to " Convert to Package Deployment Model" So I am assumming I am using Project Delployment model.
I am getting this error when I try to connect to SSIS
TITLE: Connect to Server
------------------------------Cannot connect to <DB SERVER NAME>.
------------------------------
ADDITIONAL INFORMATION:Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476
------------------------------
Connecting to the Integration Services service on the computer "<DB SERVER NAME>" failed with the following error: "Access is denied."
By default, only administrators have access to the Integration Services service. On Windows Vista and later, the process must be running with administrative privileges in order to connect to the Integration Services service. See the help topic for information on how to configure access to the service.
For help, click: http://go.microsoft.com/fwlink/?LinkId=220763
------------------------------
Connecting to the Integration Services service on the computer "<DB SERVER NAME>" failed with the following error: "Access is denied."
By default, only administrators have access to the Integration Services service. On Windows Vista and later, the process must be running with administrative privileges in order to connect to the Integration Services service. See the help topic for information on how to configure access to the service.
------------------------------
BUTTONS:OK
------------------------------
I am the an SA Admin on both SQL and at the server level.
Don't connect to integration services, connect to the database engine. If you are using an SSIS Catalog, you shouldn't be connecting to the Integration Service.
Seeing that access denied message makes me wonder if it is related to the other issue you are seeing...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
January 30, 2017 at 12:39 pm
Hello ALL...
I was able to schedule the SSIS package via SSIS import process after running the fix listed above (access denied issue to SSIS). I am waiting on the Client to confirm the SSIS package ran correctly. As time permits I will re-do the package confirming its deployment mode be set to the correct SQL version as suggested.
Thank you ALL for the help.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply