SSIS package works with windows account, fails with sqlserver sa account - ssis

Having some SSIS permissions issue.
I am calling the SSIS package in my .net console application with:
Package pkg = app.LoadFromSqlServer(packagePath, serverName, serverUsername, serverPassword, dtsEvents);
It is working when manually running it using the windows accout, but fails with the above call in my console application.
Shouldn't it work with the sql server sa account?

There are plenty of reasons for it to fail when run under different account, to avoid trying to fix it blindly, you should get the error information. It looks like you are supplying dtsEvent parameter - so your app should get the error message. Another way to get it to examine package.Error collection after execution, or enable SSIS logging and check the error log.
Once you have the error message, update the post :)
There is also a KB article dedicated to troubleshooting such errors:
http://support.microsoft.com/kb/918760/.
But it just lists lots of possible error causes - to find out your issue, you need to get the error message first.

This generally happens when you have sql queries that use linked server to access a database on a different server.

Related

SSIS Package error - Illegal operation attempted on a registry key that has been marked for deletion

We have a package that will be triggered through MVC application by invoking store procedure which creates a execution request for the Package. MVC app is hosted on different server and DB is on different server. This error started occurring after 3 months of Windows Server 2019 migration.
Package executes successfully most of the time, but fails once or twice per day with the following errors. After re-executing the package immediately it succeeds. Error occurs in the below order.
Illegal operation attempted on a registry key that has been marked for deletion
Failed to acquire connection. Connection may not be configured correctly or you may not have the right permissions on this connection.
Upon capturing the "ISServexec.exe" process dump and analyzed through DebugDiag, we came to know the below details.
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due to the following error: 800703fa Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA).
System.InvalidOperationException: The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.
System.Runtime.InteropServices.COMException: Illegal operation attempted on a registry key that has been marked for deletion.
Microsoft.SqlServer.Dts.Runtime.DtsGenericException: Illegal operation attempted on a registry key that has been marked for deletion.
Note:
Package doesn't have any excel reading operations. Just source table to target table load (both same database).
We have validated the MDAC version in the DB server as 6.3.
App Server: Windows 2019 with .Net framework 4.8 installed.
DB Server: Windows 2019, SQL Server 2019, SSIS v15, .Net framework 4.8.
Package executed using domain service account.
We have triggered the Package through SQL job and Package did not fail at all. Almost 200 executions tested. This failure is random and only fails when store procedure invoked through MVC application.
We have used ProcMon to collect the "ISServexec.exe" logs and only thing we noticed is hive unloaded and no errors.
SQL Profiler didnt even capture the error.
Package is not failing at the same step when this error occurs.
Package logging is configured to write errors in event log, but in event log only "package is failed" information is captured.
Package configured to use Oledb connection type. SQL Native client and MSOLEDB providers are used and error occurs in both the providers.
Package has been upgraded to SQL 2019. Hence we created a new Package in Visual Studio 2019 from scratch and this also fails with same error.
No errors captured in SQL Server extended events.
My Questions:
What are possible ways to validate the service account holds necessary permissions when the above error happens. Is this required ?
Is there any tools that I can use to debug and find the cause of the error or additional information ?
Is this oledb driver issue ?
How to capture any logs at windows server level when package execution happens.
Sorry for the detailed explanation. Any suggestions would be greatly appreciated.

Error message when an SSIS package runs that is scheduled to run as a SQL Server Agent job: "An OLE DB error has occurred. Error code: 0x80004005"

I am receiving the following error in SSIS "An OLE DB error has occurred. Error code: 0x80004005" for each of my data flow tasks.
When I set 'delay validation' to 'True' for all data flow tasks and execute my packages the integration works okay.
However the SQL agent job doesn't run.
As far as I can tell, the reason for this is due to the 'to_update' temporary tables I have set up to act as a middle man. The Microsoft article below seems to back this up.
https://support.microsoft.com/en-us/topic/error-message-when-an-ssis-package-runs-that-is-scheduled-to-run-as-a-sql-server-agent-job-an-ole-db-error-has-occurred-error-code-0x80004005-6a687a1f-917a-d3ae-4d3a-44e7dae82988
As the article says my next step would be to 'change the permissions for the Temp directory of the SQL Server Agent Service startup account. Grant the Read permission and the Write permission to the SQL Server 2005 Agent proxy account for this directory.' however I honestly have no idea where I would do this (I'm new to the world of SSIS!)
If someone could point me in the right direction that would be much appreciated.
There are a few things to take into account, the delay validation might be a red herring and nothing to do with the error or it might be that the Agent is calling an older version of the package that doesn't delay validation. So first of all make sure the package with the delay validation is deployed correctly and it is the one being run by SQL Agent.
Then, if the problem continues it could be permission or that the Temp directory is running out of space, worth checking it.
Finally, if it comes to permission problems then whoever is in charge of maintaining the DB, I'm assuming there is a DBA, should check what account is running the package from SQL Agent and make sure it has the right permissions.
another thing to check:
make sure the Run as is correct and if not running as 32 bit try it or viceversa.
After spending some more time it looked like the issue was actually related to disk space, the memory on the server I was using was running at 100% and the SQL agent jobs were running but very slowly and never actually ran successfully. I ended several processes and staggered when each of the SQL jobs run so they do not all trigger at once, and these are running successfully again.

Visual Studio Update Wizard MySql

I am running Visual Studio 2010, and attempting to update my Entity Framework project using the Update Wizard. When I attempt to add a single table from the MySql database, the add tab will show the table that I am attempting to add, however when I click finish, I get the following error message.
Unable to generate the model because of the following exception: 'An error occurred while executing the command definition. See the inner exception for details.
Fatal error encountered during command execution.
Fatal error encountered attempting to read the resultset.
Reading from the stream has failed.
Attempted to read past the end of the stream.
I get the same error message if attempt to create the Entity Framework from scratch. In addition, Server Explorer shows that the connection is successful when I test it.
I have also contacted Host Gator who is hosting the database and they where not able to see any issues on their side.
The problem ended up being that our shared server, was not able to handle the Update Request from the Entity Connector Framework and was timing out. Once we moved our database over to a different server we no longer had an issue.

Error code 0x80004005 when executing package as a scheduled job

The error message is:
POSTGRES dm_genders_d failed validation and returned error code
0x80004005.
I've seen several references to this almost assuredly being a permissions issue, which sounds right to me, but I have been completely unable to identify the relevant permissions.
The Postgres connection is using ODBC. The package is moving data from PostgreSQL to SQL Server. Currently both 32bit and 64bit drivers exist, but I haven't seen how to choose between them.
I have made all of the recommended changes to 32 bit for the job.
We are using Windows Authentication.
I've set up a proxy to execute the job as my user.
None of this has alleviated this error.
UPDATE: Yes, the 32 bit data source has been defined, and it is being used.
I had this error and I could solve it by Add ODBC connection in the "system DSN" instead of "User DSN" tab.
Start > ODBC Data Sources
Also I ran package with 32-bit runtime
for this: right click on your job in SQL Server Agent > properties > steps > edit
in the window that appear (Job Step Properties) you can set 32-bit runtime. (below picture)

Integration Services Throws an Error Reading Access 2007 Table

[Participant Table [1994]] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "I:\My Documents\Flamm Consulting\Migrations.accdb" failed with error code 0xC0209303. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
Frankly, I'm confused about how SSIS should connect to Access 2007 - the UI just isn't very friendly - there's no file browser, for example. I'm wondering if there's something wrong with my install - missing drivers, etc.
Two guesses - first, you're attempting to run this package on a 64-bit server, which isn't going to work without a tweak. Second, you don't have the drivers installed.
For info on the first, try here: SSIS in 32- and 64-bits.
For info on the second, try here: Interacting with Office in SSIS.
SET RUN 64 to False from the project properties.