OLEDB connection error

I could sure use some help.
I'm running Sql Server 2000 on a windows 2003 server using windows
authentication only. I can successfully run the following opendatasource
sproc from query analyzer on the windows 2003 server, however when I try to
run it from query analyzer on another machine in the network, (I've tried
both an xp and windows 2000 machine) I get a \\backupserver\share\dbdir is
not a valid path error.
select * into mytable from opendatasource('Microsoft.Jet.OLEDB.4.0','Data
Source="\\backupserver\share\dbdir";Extended properties=dBASE
IV')...myimportable
that procedure runs fine from the windows 2003 machine where sql server is
installed. I am using the exact same username/password combination on each
machine and within Sql Server. I have no trouble viewing or mapping the
backupserver share from any of the machines. It seems like an
impersonation/delegation problem but I haven't been able to figure it out.
There are no firewalls involved. It's a local LAN and the user login has
administrative permissions on all machines.
Any help would be greatly appreciated.
Thanks,
J Demory
Can the user execute:
xp_cmdshell 'net view \\backupserver'
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||When I issue that xp_cmdshell sproc I get the error below:
System error 5 has occurred.
NULL
Access is denied.
NULL
NULL
However when I issue that from a cmd prompt it works fine.
Any ideas?
Joe
"Kevin McDonnell [MSFT]" wrote:

> Can the user execute:
> xp_cmdshell 'net view \\backupserver'
>
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||What account is SQLServer running under?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Kevin,
Sql Server is running on a win 2000 server, It's running under an account
'sqluser' I created and gave administrator priv to. I created the exact same
username/ password and admin priv on both the backupserver and my windows xp
developement machine. I verified 'sqluser' has full permissions on the share
and the other 2 machines. I can exec xp_cmdshell 'net view \\backupshare'
from the xp machine using query analyzer and see the share is available. I
also tried xp_cmdshell 'dir \\backupshare\budir\*.*' and get a list of files.
For some reason the jet provider will not recognize the share I'm
referencing. Has there been a change to the jet provider to prevent this or
perhaps I'm using the wrong syntax? I also verified the 'sqluser' account is
a member of the builtin\administrators.
Thanks for the help.
Joe Demory
you can also reach me via email at jdemory@.charter.net
I verified
"J Demory" wrote:

> I could sure use some help.
> I'm running Sql Server 2000 on a windows 2003 server using windows
> authentication only. I can successfully run the following opendatasource
> sproc from query analyzer on the windows 2003 server, however when I try to
> run it from query analyzer on another machine in the network, (I've tried
> both an xp and windows 2000 machine) I get a \\backupserver\share\dbdir is
> not a valid path error.
> select * into mytable from opendatasource('Microsoft.Jet.OLEDB.4.0','Data
> Source="\\backupserver\share\dbdir";Extended properties=dBASE
> IV')...myimportable
> that procedure runs fine from the windows 2003 machine where sql server is
> installed. I am using the exact same username/password combination on each
> machine and within Sql Server. I have no trouble viewing or mapping the
> backupserver share from any of the machines. It seems like an
> impersonation/delegation problem but I haven't been able to figure it out.
> There are no firewalls involved. It's a local LAN and the user login has
> administrative permissions on all machines.
> Any help would be greatly appreciated.
> Thanks,
> J Demory
>
|||I'm not aware of changes to the Jet Provider. You may have to open up a
case with the MDAC group to investigate this further.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.