Windows Server 2008 R2 x64 SP1, Sql Server 2008 x64 SP3, 访问数据库引擎x64 SP1
我有链接服务器:
EXEC master.dbo.sp_addlinkedserver @server = N'dbf2', @srvproduct=N'dbf2', @provider=N'MSDASQL', @provstr=N'DRIVER={Microsoft Access dBASE Driver (*.dbf, *.ndx, *.mdx)};'
从本地磁盘查询dbf文件时一切正常:
select * from openquery(dbf2, 'select * from c:\\V4C8MA6.dbf') a
但是从网络共享中查询时
select * from openquery(dbf2, 'select * from \\\\gefest\\upload\\V4C8MA6.dbf') a
我收到了错误:
Msg 7399, Level 16, State 1, Line 6
The OLE DB provider "MSDASQL" for linked server "dbf2" reported an error. The provider did not give any information about the error.
Msg 7350, Level 16, State 2, Line 6
Cannot get the column information from OLE DB provider "MSDASQL" for linked server "dbf2".
我尝试过不同的变体来描述路径:[],“”,“`,\”\“,.... 使用nework共享访问一切正常,sql server帐户具有需要的访问权限。但...
如何让它发挥作用?
于2012年5月4日添加:
xp_cmdchell完美地列出了目录。
这是我发现的: 我用sprovstr创建了链接服务器,指示文件的位置:
@provstr=N'DRIVER={Microsoft Access dBASE Driver (*.dbf, *.ndx, *.mdx)};dbq=\\gefest\upload'
如果我使用 sql server auth 连接到sql server,则此方法有效。
这是ProcMon在使用 dbq :
时显示的内容日期&时间:2012年5月4日上午9:57:55
事件类:文件系统
操作:CreateFile
结果:成功
路径:\\ gefest \ upload \
TID:8588
期限:0.0001988
所需访问:读取属性
处置:开放
选项:Open Reparse Point
属性:不适用
ShareMode:读,写,删除
AllocationSize:不适用
OpenResult:已打开
这是在查询中指示路径:
时
日期&时间:2012年5月4日上午9:58:53
事件类:文件系统
操作:CreateFile
结果: OBJECT PATH INVALID
路径:\\ gefest \ upload \
TID:8588
期限:0.0000819
所需访问:读取属性
处置:开放
选项:Open Reparse Point
属性:不适用
ShareMode:读,写,删除
AllocationSize:不适用
为什么sql server在第一次查询时收到对共享的所需访问权限而在第二次查询时没有?
第三个和第四个变体是使用 windows auth 连接到服务器时:
使用 dbq :
日期&时间:5/4/2012 10:02:54 AM
事件类:文件系统
操作:CreateFile
结果:拒绝访问
路径:\\ gefest \ upload \
TID:8588
期限:0.0031837
所需访问:读取属性
处置:开放
选项:打开备份,打开重分析点
属性:不适用
ShareMode:读,写,删除
AllocationSize:不适用
冒充:GAZ \ kozlovai
在查询中指明路径:
日期&时间:5/4/2012 10:02:20 AM
事件类:文件系统
操作:CreateFile
结果: OBJECT PATH INVALID
路径:\\ gefest \ upload \
TID:8588
期限:0.0000378
所需访问:读取属性
处置:开放
选项:打开备份,打开重分析点
属性:不适用
ShareMode:读,写,删除
AllocationSize:不适用
冒充:GAZ \ kozlovai
连接到共享时,Sql server会模拟。而且这个帐户'GAZ \ kozlovai'可以完全访问共享,但是sql server仍然无法打开文件...
答案 0 :(得分:0)
检查运行查询的用户标识是否具有对服务器上临时文件夹的读写权限。这是因为SQL Server将在调用用户的上下文中为查询创建临时文件,而不是SQLServer进程帐户。
编辑:我记得至少有一些这个问题的例子只是通过UNC托管的股票产生的,所以它不会在本地参考上发生。
只是为了笑容,启动XP_CMDSHELL并执行'DIR \\ SERVER \ SHARE \ FOLDER'并确保您可以通过SQL Server中的UNC与该路径通信。如果没有,您仍然需要克服访问权限问题。
最后,如果所有其他方法都失败了,并且您具有对服务器的登录访问权限,我将启动Process Monitor的副本,并在该查询触发时监视网络IO问题。