Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
Related
I have a startup package and within that I call [Execute Package] to run others. So it's like
[Start.dtsx] -> [Execute Pkg 1] -> [Execute Pkg 2] ....
This works fine when I run it under Visual Studio. After I publish to SQL Server under catalogs things doesn't seem to work properly.
Once deployed, I can see all my dtsx files including the start.dtsx. I select the start.dtsx and enter the required parameters (These parameters are set as project level parameters).
Once started and look at the execution reports; it doesn't seem to execute other packages. I see two errors though saying below.
If I view the context it doesn't give any useful information. Seems like something to do with permissions? However I am logged into my sql server instance as "sa" when running this package. I also noticed that I have a service called "CEIP service for Sql server Integration Services" running under NT Service\SSISTELEMETRY150 Does this have something to do with this? Note that when running in Visual Studio it all works perfectly.
As suggested in above comments by #Mark Wojciechowicz in comments, I configured SQL Agent to run the package by creating a step. But I had to change it's account to local system account. The default account didn't had sufficient permissions. Since it's local dev environment I switched to local account and all works fine.
My SSIS package consists of an Execute Process Task which executes some compiled python code which downloads files from a Web API.
The code works.
The package executes succesfully from Visual Studio.
Once deployed to my localhost sql server 2012 instance SSISDB, I can right click execute it and it works fine.
However, as soon as I try to invoke the package from a SQL Server Agent job, it fails with. I do not understand this but I suspect this is because I don't understand what's happening with the SSL handshake. Does SQL Server Agent reference it's own store? If so, does this mean that my store is inactivated (do I need to enable SSL for my sql server agent?) or missing a certificate?
It feels like I have tried every possible workaround - I have ensured that my sql server agent is owned by my credential, rather than a generic credential - I've even created a proxy and explicitly instructed the sql server agent job step to run under that proxy but I guess this isn't the issue. The issue is the SSL certification step.
How can I fix this?
I am building a package that performs multiple tasks and sends a success email (from script task) as last step of the package.
When running the package manually from Visual Studio the email is sent correctly. However, when running the deployed package from a Job in SQL Server the email is never sent (I have checked in the Gmail account that sends the email and it does not appear in the "Sent" folder).
I also checked the report for the package execution and I can't find the send email task, so it seems that it never actually get to the script task that sends the email.
Any ideas what the problem might be?
Thanks!
Ensure that you can send mail in SQL Server without Visual Studio involved. Also, the job from SQL Server sometimes runs as a different user than you when you login and run via Visual Studio. The problem may be that the script isn't running because the SQL Server user does not have permission to run a portion of the script. I would set this to run as an SSIS job in SQL Server and then check the SSIS log in SQL Server to see where the failure is occurring. If it is a different user issue, you can solve a multiple number of ways. You can give the SQL Server user the necessary permissions or you can setup a proxy account in SQL Server that has permission to run the job
The following link answers this question. Before deploying to SSIS, change the SQL Server version:
SSIS: script task (vs15) not work when deploy on sql server 2014
I have noticed something else while looking at the execution report, and now I am even more confused... (since other jobs that tigger emails are executed and everything is fine).
1) When executing the job from a job (executed by SQLSERVERAGENT) it seems like the task runs (since logs appear), but still the email is not sent:
2) When executing in SQL Server manually (with my user which is SysAdmin) an error appears:
I have an SSIS package that I have deployed to the file system. The owner for the package is my Windows Login. The reason for this is that it needs to write files to another server. If I make the owner NT SERVICE\SQLSERVERAGENT the error that I get is that the files on the remote server cannot be accessed.
The package itself runs under my account. The package normally takes about 5 minutes to run and works when run directly (double click, click Execute and enter decryption password). I can tell the package has run because it writes a number of logs to the file system.
I've set up a SQL Server job to run the package. The job says it's run successfully but there are no logs being written. I'm not sure where I've gone astray other than there's some account that I'm likely missing.
Has anyone else ever run into this?
The issue was that I needed to set up a proxy Account to run the SQL Server agent.
I have some DTS packages that are failing occasionally. They have some pretty comprehensive logging in the various VBScript components and both SQL and text logging are enabled in each package. The logging works fine if I run the DTS packages from the server they live on.
In practice these packages are run using DTSRun from a remote machine that only has the SQL Server Client Tools installed. As DTS runs locally, where do the logs go in this case, if they are created at all? They're not on the server, there's no database on the client to do any SQL logging to and none of the text files were created on the client or server. Is it possible to debug DTS packages run this way?
Such as it is, the answer was to ensure the full path of the text logging is set up so it's valid on the machine where DTSRun is being called. In this case I had it set to C:\DTSErrors - this folder existed on the server, but not on the client. Creating C:\DTSErrors on the client solved my problem - now text logs are being created.
I assume the SQL logging just fails silently as there's no SQL server on the client machine to log to.