如何处理pyodbc事务执行过程中的连接错误？

我写了个每周运行的Python cron脚本，用pyodbc连接SQL Server数据库，包含读写操作（插入、删除、更新）。所有写入操作都通过同一个pyodbc游标在同一SQL事务中执行——因为怕出现高级错误时部分写入提交、部分未提交，那样就得手动恢复数据库，而且任务中途没法恢复，部分完成的记录会导致任务和数据异常，所以必须保证每次运行前数据库状态一致。

出错时我会执行cursor.rollback()；没出错的话，就在脚本结束、关闭数据库连接前执行cursor.commit()。

遇到的部分错误如下：

('08S01', '[08S01] [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x274C (10060) (SQLExecDirectW)')
('08S01', '[08S01] [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure (-2147467259) (SQLEndTran)')

我试过用带重试标记的while循环捕获错误并重连SQL Server，但这样会丢失未提交的事务变更，基本只能重启整个任务。

疑问 #

1. 是否可以创建游标并继续中途断开的事务？
2. 事务完成前遇到网络错误应如何处理？
3. 是否应每次写入后提交，重构任务以支持插入失败时恢复？此时遇连接问题可重连，但不确定可行性是否优于失败后重启整个任务？

1. 能否继续中途断开的事务？ #

不行。一旦网络连接断开，SQL Server会自动回滚当前未提交的事务——数据库无法确认客户端后续是否还会操作，为了保证数据一致性，会直接终止该事务。而且pyodbc的连接和游标绑定于当前网络会话，断开后原会话失效，新的游标和连接属于全新会话，无法关联到之前的事务。

2. 事务中遇网络错误的处理方式 #

• 立即终止当前任务：事务已被数据库自动回滚，继续执行无意义，直接退出脚本，后续由cron重新触发或手动重启。
• 添加预检查与重试机制：执行事务前先做简单连通性测试（比如执行SELECT 1），连不上就重试几次再启动任务；执行过程中出现网络错误，记录详细日志（错误时间、执行到的步骤），方便排查根源（比如网络不稳定、数据库服务器负载过高）。
• 缩短事务执行时长：事务执行越久，网络中断概率越高。可检查是否能在保证一致性的前提下拆分逻辑，或优化SQL语句（比如用批量操作代替单条执行），减少事务运行时间。

3. 单步提交 vs 全事务提交的选择 #

需结合业务场景判断：

• 单步提交+可恢复任务：如果能把任务拆分成独立小单元，每个单元完成后提交，同时用任务状态表记录各单元执行进度，遇到网络问题时可重连后从上次失败的单元继续。这种方式适合任务可分段、单元间无强依赖的场景，但需要额外做进度跟踪，若单元间有强关联（比如先删后插，删完提交后插失败会导致数据不一致）则不适用。
• 全事务提交+失败重启：如果业务要求所有操作必须原子性完成（要么全成要么全败），保持全事务方式更稳妥。虽然遇到网络错误要重启，但能保证数据一致性，无需处理部分提交后的脏数据。你的场景提到“无法中途恢复任务，部分完成会导致异常”，这种情况下全事务+失败重启更合适——每周一次的任务重启成本不高，远低于数据不一致的修复成本。

无论选择哪种方式，都要做好日志记录：记录每次任务的执行时间、步骤、错误信息，方便排查问题和数据恢复。

内容的提问来源于stack exchange，提问作者Quinn Nolan