SSIS package fails but SQL Server Agent marks success - sql-server

I have a SQL Server Agent job with two steps:
Executes an SSIS package with a task for importing a CSV and another task for sending an email saying that the import was successful. The step's On Failure action is set to Quit the job reporting failure. The package source is File System.
WIth tsql, updates a table saying that DTS package executed correctly.
When I run the dtsx package manually, the job fails with the import and the email is never sent.
When SQL Server Agent executes the job, it says that the first step ran successfully (the package) and then runs the 2nd step which updates the table. The email is not sent, so that's why I know it failed, but the table is updated.
Why doesn't SQL Server Agent reflect that the SSIS Job failed?
[SSISDB].[catalog].[executions] is empty and returns 0 rows.
The SQL Server Agent job history says that the job was successful.

Related

SSIS package failing via Credential account

I have one package which loads data from excel using ace.oledb.12.0 driver to SQL server(same server where SQL agent service is running.).
When I ran this Step from SQL Agent using Infrastructure Service account it succeed.
When I ran this step using a credential account it is stopping the job as a failure 'Unexpected Termination'.
Funny part is this is running exactly fine for files with data size low(100kb-300kb) when run from both Infrastructure Service account and a Credential account.
But for my current file having size 4.5 mb it is failing via Credential account.
Is there a way I can capture why the job is getting terminated?
Disclaimer: I work for ZappySys
Looks like you need to find out detailed error message to know more. Did you deploy package using SSIS Project Mode in SSISDB or running as File System Package? When you run SSIS Package via Agent Job you will see very limited error message and many times its useless. So better to run package under SSIS Catalog so you see full execution log. If that is not possible then try to Add Some SSIS Log Provider (see below) for better logging on error messages.
How to add SSIS Log Provider in your package
How to view execution log in SSIS Catalog (See Step#10 in this link)

SSIS - Email not sent from deployed package

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:

execute sql server agent job task in ssis error : Failed to lock variable"RunIs" for read access with error 0xC0010001

I am using SQL Server 2016 and SSIS. I have a package in which I am calling a sql server job.
My job have just one step as PowerShell command for transfering all files from one directory to another directory between two servers.
When I run my job from SQL server, it works well.
When I run my package from VisualStudio, every things is ok, but after deploying my project to sql server, when I want to run this package from SQL Server, I have this error :
Execute SQL Server Agent Job Task: Error: Failed to lock variable "RunId" for read access with error 0xC0010001 "The variable cannot be found. This occures when an attempt is made to retrive a variable from the Variable collection on a container during execution of package, and the variable is not there. The variable name may have changed or the variable is not being created.".
I deleted the Execute sql server agent job task from my package and I redeployed my project and now I do't have this error. It is clear that error is about Execute sql server agent job task.
I have more than 2000 files in source directory and it takes several minutes to transfer all files to destination directory.
Edit1 : I have several Task and component in my package and the last ones is Execute sql server agent job task and i don't have Execute T-SQL Statement Task.

SQL Job unknown user or bad password

We currently have a SQL Server 2012 job that fails and unable to figure out the problem. The SQL job calls a SSIS package and if I run the package via Integration Services it runs successfully. However when running the job it returns the following in Windows Event Viewer:
SQL Error : Logon failure: unknown user name or bad password.
SQL Job History Error:
Error: 2017-04-28 09:43:40.17
Code: 0x00000006
Source: Create Temp Tables 1
Description: The script returned a failure result.
End Error
DTExec: The package execution returned DTSER_FAILURE (1).
There doesn't appear to be any information that helps resolve the issue. We don't appear to have any proxies setup. All other jobs that reference a SSIS package run successfully.
I found the cause of the error as there was a variable set in the package that was referencing a secondary server. Changed the connection string and job is back up and running.
To run SSIS package through JOB you need to set a password in the package
And when informing the package will be requested the password so that you can include in the job

Unable to process a cube via a job that calls SSIS on another server

We have recently moved an SSAS cube & its database to a different server. Both are SQL Server 2012 RTM.
We are using an SSIS package to handle processing of the day's partition. (The same package as on the server we restored from) The job exists on the box with the SSAS, but the job STEP points at a SQL Server 2012 box running SSIS.
If we run the SSIS package, it succeeds. However, if we try to run the package via the agent on the SSAS box, it fails. That user has been added as a SSAS server admin just in case, but hasn't changed anything.
Also, we set up a job running the SSIS package on the SSIS server. It works.
When the job fails, the SSIS error message: "A connection cannot be made. Ensure that the server is running."
Only message in the server event logs: "Package "Process_Partitions" Failed"
If we run an SSAS profiler trace, we get 3 events: Progress Report Begin, Notification, Progress Report End, all at the same time, but without anything else.
One other thing worth mentioning: we have two instances of SSAS on the server: traditional (the default instance) and tabular.
Any help greatly appreciated.
May be a double hop issue (Kerberos Delegation). Essentially, the job passes the SQL Server Agent credentials on [Server with Job] to [Server with Job Step] which then passes the credentials to [Server with Cube].
[Server with Job] - First Hop - [Server with Job Step] - Second Hop - [Server with Cube]
If this is the case and Kerberos Delegation isn't properly configured, the trace on the cube or tabular model should reveal an Anonymous NTUsername.

Resources