如何通过存储过程执行修复 pyodbc 错误
How to fix pyodbc error with stored procedure execution
我正在服务器上设置一个新的 VM 以卸载 SQL 服务器数据库从我的笔记本电脑加载。这样做时,我希望能够通过 Python 在我的数据库中执行存储过程(没有参数,只有 'exec storedprocedure'),但它不起作用。
当通过批处理文件和 SSMS 使用 sqlcmd 时,存储过程调用有效,但我想让它全部基于 python。
存储过程按照以下一般格式附加事实表:
--staging tbl drop and creation
if object_id(stagingtbl) is not null drop tabl stagingtbl
create table stagingtbl
(fields datatypes nullable
)
--staging tbl load
bulk insert stagingtbl
from 'c:\filepath\filename.csv'
with (
firstrow = 2
, rowterminator = '\n'
,fieldterminator = ','
, tablock /*don't know what tablock does but it works...*/
)
--staging table transformation
; with cte as (
/*ETL process to transform csv file into my tbl structure*/
)
--final table load
insert final_tbl
select * from cte
/*
T-SQL update the final table's effect to date, based on subsequent effect from date.
eg:
id, effectfromdate, effecttodate
1,1/1/19, 1/1/3000
1,1/10/19, 1/1/3000
becomes
id, effectfromdate, effecttodate
1,1/1/19, 1/10/19
1,1/10/19, 1/1/3000
*/
存储过程在 sqlcmd 和 ssms 中工作正常,但在 python (pyodbc) 执行查询 'exec storedprocedure' 时,我收到错误消息:
pyodbc.ProgrammingError: ('42000', '[42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]
Cannot bulk load because the file "c:\filepath\filename.csv" could not be opened.
Operating system error code 3(The system cannot find the path specified.). (4861) (SQLExecDirectW)')
当有csv文件时,路径和文件名没有拼写错误,我双击就可以打开csv,没有人打开csv。
通过继续实验,我确定问题不在于 python 或 pyodbc。在我的笔记本电脑(数据库的主机)上的 SSMS 中,存储过程工作正常,但在 VM 上的 SSMS 中,存储过程会导致相同的错误。这告诉我,我的问题不是根本问题,我还有更多的挖掘工作要做。错误(在 SSMS 中)如下。
Msg 4861, Level 16, State 1, Procedure Append_People, Line 71 [Batch Start Line 0]
Cannot bulk load because the file "N:\path\filename.csv" could not be opened. Operating system error code 3(The system cannot find the path specified.).
确定问题出在 SSMS 后,我扩大了搜索范围,发现问题是 bulk insert
命令的路径必须与托管数据库的机器相关。所以在虚拟机(客户端机器,直到我迁移数据库)中,当我使用路径 c:\
认为它是虚拟机的 c:\
驱动器时,存储过程正在查看我的笔记本电脑的 c:\
因为它是主机。由此我还了解到,在共享驱动器 (N:\
) 上,访问是委托的,这是它自己的问题 (https://dba.stackexchange.com/questions/44524/bulk-insert-through-network)。
所以我会先专注于迁移数据库,然后这将解决我的问题。感谢所有试图提供帮助的人
我正在服务器上设置一个新的 VM 以卸载 SQL 服务器数据库从我的笔记本电脑加载。这样做时,我希望能够通过 Python 在我的数据库中执行存储过程(没有参数,只有 'exec storedprocedure'),但它不起作用。
当通过批处理文件和 SSMS 使用 sqlcmd 时,存储过程调用有效,但我想让它全部基于 python。
存储过程按照以下一般格式附加事实表:
--staging tbl drop and creation
if object_id(stagingtbl) is not null drop tabl stagingtbl
create table stagingtbl
(fields datatypes nullable
)
--staging tbl load
bulk insert stagingtbl
from 'c:\filepath\filename.csv'
with (
firstrow = 2
, rowterminator = '\n'
,fieldterminator = ','
, tablock /*don't know what tablock does but it works...*/
)
--staging table transformation
; with cte as (
/*ETL process to transform csv file into my tbl structure*/
)
--final table load
insert final_tbl
select * from cte
/*
T-SQL update the final table's effect to date, based on subsequent effect from date.
eg:
id, effectfromdate, effecttodate
1,1/1/19, 1/1/3000
1,1/10/19, 1/1/3000
becomes
id, effectfromdate, effecttodate
1,1/1/19, 1/10/19
1,1/10/19, 1/1/3000
*/
存储过程在 sqlcmd 和 ssms 中工作正常,但在 python (pyodbc) 执行查询 'exec storedprocedure' 时,我收到错误消息:
pyodbc.ProgrammingError: ('42000', '[42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]
Cannot bulk load because the file "c:\filepath\filename.csv" could not be opened.
Operating system error code 3(The system cannot find the path specified.). (4861) (SQLExecDirectW)')
当有csv文件时,路径和文件名没有拼写错误,我双击就可以打开csv,没有人打开csv。
通过继续实验,我确定问题不在于 python 或 pyodbc。在我的笔记本电脑(数据库的主机)上的 SSMS 中,存储过程工作正常,但在 VM 上的 SSMS 中,存储过程会导致相同的错误。这告诉我,我的问题不是根本问题,我还有更多的挖掘工作要做。错误(在 SSMS 中)如下。
Msg 4861, Level 16, State 1, Procedure Append_People, Line 71 [Batch Start Line 0]
Cannot bulk load because the file "N:\path\filename.csv" could not be opened. Operating system error code 3(The system cannot find the path specified.).
确定问题出在 SSMS 后,我扩大了搜索范围,发现问题是 bulk insert
命令的路径必须与托管数据库的机器相关。所以在虚拟机(客户端机器,直到我迁移数据库)中,当我使用路径 c:\
认为它是虚拟机的 c:\
驱动器时,存储过程正在查看我的笔记本电脑的 c:\
因为它是主机。由此我还了解到,在共享驱动器 (N:\
) 上,访问是委托的,这是它自己的问题 (https://dba.stackexchange.com/questions/44524/bulk-insert-through-network)。
所以我会先专注于迁移数据库,然后这将解决我的问题。感谢所有试图提供帮助的人