views:

35

answers:

2

hi,

i created a SSIS package on my development machine which simply: 1) Deletes records from weak table in database. 2) Loads file from filesystem into weak table in database. 3) The package is called from an asp.net page

When i run the package manually on my machine it works, when the protection level is EncryptSensitiveWithUserKey. When i deploy i change the protection level to 'DontSaveSensitive'.

When i run the web application , i get this error - "An OLE DB error has occurred. Error code: 0x80040E4D. An OLE DB record is available. Source: "Microsoft SQL Native Client".

Unfortunately i don't have much access to the SQL Server 2005 instance on the remote server to run it manually.

When i deploy the package, i include an xml config file and include the password in the connectionstring property.

Also i've turned on logging, but cannot see anything written to Event Log or SQL Server. Can someone pls refer me to log table that SSIS writes to? I've checked in MSDB. Is it sysdtslog90?

Can someone please give me some pointers to what i can use to troubleshoot this.

regards

Kojo

A: 

Have you checked the permissions of the user account that is calling the SSIS package to make sure they have adequate privileges to all tables/resources involved?

The ASP.Net Worker Process is typically setup to run under the Network Service account, or even the user on the page (if impersonation is turned on) and they don't have proper authority to access the tables specified.

Dillie-O
I know the database account has sysadmin access to the application's database and within msdb database, It has also been added to dt_dtsadmin,dt_dtsltdser and dt_dtsoperator, public and db_datareader. I'm using impersonation to navigate through the website and the impersonated user and network service has access to both application's database and msdb database.
Kojof
A: 

The table name for logging is sysdtslog90. It will be in the database that matches the database for the connection you specified in the logging. Also, you must have picked the Sql Server logging provider to use that table. Once you track down this table and look at it, you should be able to see the messages that were sent when the application failed.

William Todd Salzman
Thanks for clarifying that. The table is empty and i have chosen the sql server logging provider. Do you know why the database password is not passed on, even though the protection level on the package is 'DontSaveSensitive'.
Kojof