SSIS Excel 临时目录权限问题

Question

Data Flow Task:Error: Excel Source failed the pre-execute phase and returned error code 0xC02020E8.

Data Flow Task:Error: Opening a rowset for "Sheet$" failed. Check that the object exists in the database.

1. SSIS Package was working prior to a few days ago.
2. The Package successfully downloads the.xlsx file from the source server
3. The package runs successfully when manually initiated from SSISDB
4. The package fails when run from the SQL Job
5. The proxy is setup correctly
6. When I put the domain account that is configured on the proxy in the Administrators group on the SSIS server the job runs successfully
7. It SEEMS to be related to the size of the Excel spreadsheet from everything that I have read in researching the issue.

The Job running the failing package runs three other packages in order. Package 1 and 3 fail, Package 2 and 4 work fine. All of the packages are consuming different Excel spreadsheets.

No - I cannot get the provider to provide us.csv files (well - we're asking but there's no guarantee that they'll do it).

No - I'm not installing Excel on the SSIS server so that our BI developers can write a program to convert the.xlsx to.csv - but I'm thinking about installing Python so that they can do it

No - I'm not going to keep the service account running the job in the Administrators group on the server

Everything I've looked at implies that it's a permissions issue on some temp folder that the Access Database drivers (we were using the ACE 12 drivers - and now we're using the ACE 16 drivers - 64 bit) are writing their temp data to that the service account doesn't have access to.

I've granted Full Control to the service account running the job (which is different from the service account running the SSIS services)

C:\Users<ssis_service_account>AppData\Local\Temp

c:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp

c:\users\Default\AppData\Local\Temp

c:\windows\serviceprofiles\localservice\AppData\Local\Temp

c:\Windows\Temp

no joy.

I also logged into the server locally using the proxy account credentials so that a user profile for that proxy account would get created. The job ran once and then failed every time after that.

The ONLY thing that seems to work is to give the Proxy administrator access to the server. Needless to say - this does not appear to be a good thing.

Any ideas?

And yes - I'm sure that the.xlsx file has not changed its format - nor has it changed the worksheet name that the data resides on - as, as I've stated, the package runs fine when manually initiated. It's when it's run by the SQL Agent job is where it fails - and it only fails if the Proxy is not on the local server administrators group.

Lastly, we have tried using 32-bit mode but we can't have the 32-bit and 64-bit of the driver installed at the same time.

SQL Server 2016, Windows Server 2012 R2

Answer 1

Check your system log for any COM server application error entry. if you found the entry, then.

1. Add user to DCOM group
2. Add user to Microsoft Sql Server Integration Services
3. Add user to Microsoft Excel Application

Answer 2

You have 4 steps and all doing the same thing on different excel files right? two of those steps succeed with the same user and two fail right?

Troubleshooting steps I will take are.

1. Ensure all 4 folders have the same permissions. Also check file permissions, as this could be different from the folder permissions.
2. Check the file source, I had a very similar problem and noticed that if I open and save the file before putting it in the folder the process succeeds. I asked the vendor to always open the file to ensure it was good and then save it.. problem solved for me although they haven't still figured that file out. 3.I will put the problem in a folder and success to check if it is a file problem or folder problem

Answer 3

I just finished troubleshooting with Process Monitor. It appears that there is something called office cache, and it's location it's elusive... to say the least. For the default profile in modern windows versions should be c:\Users\Default\AppData\Local\Microsoft\Windows\NetCache\Content.MSO. Absolutely non-viable...