Microsoft.ACE.OleDB.12.0 + Windows Server 2008 R2 +电子表格通过UNC路径访问SharePoint = :(

Question

Here's a very specific question. I have a developer who is attempting to open an excel document through the UNC path \\\\sharepoint.site.com\\sites\\site\\library\\folder one\\test.xlsx , using the Microsoft.ACE.OleDB.12.0 provider, in C# code running on IIS7 on Windows Server 2008 R2 .

Once we sorted out even getting the provider to be recognized on the server, we ran into the following error:

The Microsoft Office Access database engine cannot open or write to the file '\\\\sharepoint.site.com\\sites\\site\\library\\folder one\\test.xlsx'. It is already opened exclusively by another user, or you need permission to view and write its data

Looking at the Security log on our SharePoint WFE, I can see that the app pool identity is logging in successfully upon the call to conn.Open() , and it does indeed have Full Control over the site being accessed. So what gives? Has anyone by chance run into this before? The code being used is below:

string connectionString = @"Provider=Microsoft.ACE.OLEDB.12.0; Data Source=\\sharepoint.site.com\sites\site\library\folder one\test.xlsx;Extended Properties=""Excel 12.0;""";

OleDbConnection conn = new OleDbConnection(connectionString);

conn.Open();

Answer 1

UNC pathing was my exact issue. On my local machine, I could connect to my desired excel document and work with rows from the excel document without an issue. When I however deployed my website to the server, it would connect to the excel document using the below connection string but no rows would be returned. My connection string was:

string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties=\"Excel 12.0;HDR=YES\";", filePath); //where filePath is the excel document file name

Using OleDbConnection.GetOleDbSchemaTable(OleDbSchemaGuid.Tables, null); to return the TABLE_NAME/Sheet of the excel doc which returned no results on the server.

What I found was that the web server (IIS) connected via UNC to retrieve the website files on another server but as David mentions above, ACE is very temperamental with UNC pathing. Using System.Web.HttpContext.Current.Server.MapPath sorts this out. Here is my final connection string:

string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties=\"Excel 12.0;HDR=YES\";", System.Web.HttpContext.Current.Server.MapPath(filePath));

Answer 2

Turns out that it didn't like the load balanced address for the farm for whatever reason. Explicitly targeting one of the Web Front-Ends in the UNC path worked. I hope this helps someone else out there who encounters the same issue!