Re: OPENROWSET

In a couple of your examples, you are using admin shares.
And yes, those would require that the security context be an
administrator on the box. Use regular shares instead of
admin shares (C$, D$ - those with the dollar signs are the
default admin shares).

-Sue

On Thu, 8 Jun 2006 12:54:49 -0500, "Sol Rosenburg"
<jvandyne@xxxxxxxxx> wrote:

We've set the SQL Service to run on a domain admin account.
Bad practice yes, but trying to resolve issue.
Still errors with the same message.

We're trying to execute the openrowset command in a production environment,
but can't get anything to run unless the account
executing the SQL is admin on local box. Any directions to look?


"Sue Hoegemeier" <Sue_H@xxxxxxxxxxxxx> wrote in message
news:pk6s72lflnf7r0n8p2ok5uvtr816aiv429@xxxxxxxxxx
Yes...0x80004005 often indicates a permissions issue.
Check the permissions for the SQL Server service account and
make sure it has access to the network resources,
directories.

-Sue

On Wed, 31 May 2006 13:35:37 -0500, "Sol Rosenburg"
<jvandyne@xxxxxxxxx> wrote:

I'm having problems with OPENROWSET with excel file.

I have excel file in network accessible folder. File opens in excel by
entering each of the following in explorer address

\\server\wwwroot$\file.xls
\\server\file.xls
\\server\c$\inetpub\wwwroot\file.xls

However OPENROWSET only works for
\\server\wwwroot$\file.xls
Otherwilse error message returned =
Server: Msg 7399, Level 16, State 1, Line 3
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider
did not give any information about the error.
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IDBInitialize::Initialize returned 0x80004005: The provider did not give
any information about the error.].

I think there might be a permissions problem somewhere : maybe domain,
maybe
sql service account. Question is: what context / account is used to
execute
openrowset for each of above?




.