OWonlyWeb

Knowledge

Session: 2026-05-14 11:17:00 GMT+8

_raw/openclaw/p1-memory-2026-05-25/memory/2026-05-14-1117.md

Session: 2026-05-14 11:17:00 GMT+8

  • Session Key: agent:main:dingtalk-connector:direct:17600802669338842
  • Session ID: 769abb20-7240-4dfe-875f-2a373314c87c
  • Source: dingtalk-connector

Conversation Summary

assistant: 我继续往下挖一下：重点查 101 里有没有指向 105 的同步代码，以及 104 是否存在结构/约束导致单条插入失败。 assistant: reply_to_current 我继续查了一轮，现在可以把判断收得更准一点：

先说结论

`081003` 没进 104，不像是“104 库字段不兼容”导致的。 更像是：

  1. 101→104 的同步逻辑确实只在 `zhc_Ven_Ins` / `zhc_Ven_Con_Ins` 里；
  2. 而这套触发器当前是禁用状态；
  3. 105 里之所以有 `081003`，不是因为这套触发器同步过去的，而是通过另一条路径进去的。

我这次查到的关键点

1）101→104 的代码路径我又确认了一遍

zhc_Ven_Ins 的正文里，确实包含：

  • INSERT INTO UFDATA_104_2018..Vendor
  • INSERT INTO UFDATA_104_2018..VendorBank
  • UPDATE UFDATA_104_2018..Vendor
  • 删除/补插 UFDATA_104_2018..VendorBank

也就是说，101 到 104 的供应商主档同步，设计上就是靠这个触发器。

2）101 里没查到指向 105 的同类同步代码

我继续搜了 UFDATA_105_2019，在 101 库里没有搜到直接指向 105 的供应商同步 SQL。

这反过来说明：

  • 105 里的 `081003` 不是从 `zhc_Ven_Ins` 这条逻辑来的
  • 也不是我当前能在 101 库里直接搜到的“101→105 跨库 SQL”

3）104 的 Vendor 表结构看起来没有明显卡点

我把 104 的 Vendor 关键字段又过了一遍：

  • cVenAbbName 非空
  • 一些 bit 字段非空
  • dVenCreateDatetime 非空

但 zhc_Ven_Ins 插入 104 时，这些字段都在显式传值，不是靠默认值兜底。 而且 081003 在 105 里能落进去，时间、人员、主档字段都一致，说明这条数据本身并不脏。

所以目前没有证据表明是 081003 这条数据格式异常，导致 104 插入失败。

4）105 的存在，说明有另一条来源

105 里这条数据是：

  • 同样的供应商编码
  • 同样的名称
  • 同样的建档/修改时间
  • 同样的创建人/修改人

这太像“同一次业务动作生成的数据”了。 所以更大的可能性是：

可能性 A：105 是通过别的同步程序/接口写入的

不是 SQL 触发器，而是：

  • U8 外挂/二开程序
  • 接口服务
  • 定时任务
  • 手工执行的同步脚本

可能性 B：105 是人工补录，但参考了 101 原始数据

这种可能也有，但从时间完全一致看，我觉得概率低于 A。

目前最像真实情况的解释

对 104：

081003 没有进入 104，大概率就是因为当时 101→104 的触发器链路没有执行。

对 105：

081003 能进入 105，说明 105 走的是另一套同步/导入路径，不依赖 `zhc_Ven_Ins`。

但还差最后一块证据

我现在已经基本排除了“104 字段结构本身卡死”这种简单原因。 下一步如果要彻底坐实，就该查：

  1. 105 库或外围系统有没有供应商导入/同步程序
  2. SQL Server Agent 作业
  3. 二开日志 / 中间表 / 接口表
  4. 104 是否曾经插入失败但没有日志落库

我建议下一步直接查这两类

方向 1：查 SQL Server Agent 作业

看有没有：

  • 供应商同步
  • 基础档案同步
  • 账套同步
  • 101→105 或 101→104 的任务

方向 2：查二开同步日志表 / 接口表

重点看：

  • ZHC_UFSynlog
  • ZHC_Synlog
  • EF_Base_Information
  • IB_AsyncPluginTask
  • 其它带 sync / zhc / ef / vendor 的表

你要的话，我就继续按这两条线往下查，尽量把： “105 是怎么来的” 和 “104 为什么没进” 锁到具体对象。 user: 可以，并且可以核对一下101账号里面有多少供应商是没有同步到104和105的 assistant: 我直接查数量和来源线索。先跑缺失统计，再看作业/日志。 assistant: reply_to_current 查完了，结果很清楚：

核对结果

UFDATA_101_2018 一共有 1459 个供应商。

其中：

  • 没有同步到 104 的：16 个
  • 没有同步到 105 的：0 个
  • 同时没有同步到 104 和 105 的：0 个

也就是说：

101 里的供应商已经全部存在于 105。 现在异常只出在 104。

101 有、104 没有、但 105 有的 16 个供应商

按修改时间倒序，这 16 个是：

  1. 081004 广州日胜网布贸易有限公司(冯文添）
  2. 081003 江苏紫荆花复合材料有限公司
  3. 08964 中衡（厦门）计量检测服务有限公司
  4. 08963 东莞市天一精密机电有限公司
  5. 08962 厦门汇青同创智能科技有限公司
  6. 08961 佛山市顺德区迪雅晟机械制造有限公司
  7. 081002 绍兴旭码纺织品有限公司
  8. 05433 东莞市寮步俱进焊接设备有限公司
  9. 05432 佛山市孜达机电设备有限公司
  10. 05431 厦门市兴东顺机械设备有限公司
  11. 05430 泉州市永顺昌缝纫设备有限公司
  12. 081001 广州卓阳纺织有限公司
  13. 08039 重庆京东海嘉电子商务有限公司
  14. 081000 苏辉跃（泉州辉溢纺织）
  15. 08038 杭州今日头条科技有限公司
  16. 06084 广东海达仪器有限公司

现在可以得出的判断

这基本说明两件事：

1）105 有自己独立的同步/导入路径

因为 missing_105 = 0，所以 105 不是偶然有几条，而是全量都能跟上。 这几乎可以确定：

  • 105 不是依赖 `zhc_Ven_Ins`
  • 或者至少 不只依赖 `zhc_Ven_Ins`

2）104 的问题是“从某个时间点开始漏同步”

这 16 条大多集中在：

  • 2026-03-06
  • 2026-03-13
  • 2026-04-07 ~ 2026-05-12

这个分布很像：

  • 104 这条同步链路从 2026-03 之后基本没再正常补进去
  • 而 105 同期仍在持续同步

关于你最关心的 081003

081003 不是孤例。 它属于这 16 条“只漏 104、不漏 105” 的一部分。

所以更准确的结论是：

不是 081003 这条数据特殊，而是 104 的供应商同步链路整体出了问题。

日志线索

我还看了 ZHC_UFSynlog，目前看到的都是：

  • cAccount = 100
  • 单据类型多是 销售订单 / 采购订单

暂时没看到供应商档案同步相关记录。

这说明：

  • 要么供应商同步根本不记这里
  • 要么 104 这条同步失败时没写进这张日志表

目前最像真实原因

综合现在所有证据，我认为概率最高的是：

104 供应商同步链路失效了

而 105 有另一条正常的同步机制，所以 105 一直完整，104 从某一时段开始持续漏。

这比“单条数据脏”“某条记录特殊失败”更符合现状。

下一步我建议

我可以继续给你查两件最关键的事：

  1. 104 为什么会从那段时间开始持续漏
  • 查 104 侧是否有单独的触发器/二开逻辑/目标表异常
  1. 105 到底是通过什么机制做到全量同步的
  • 查 105 库里的对象、接口表、作业、二开对象

如果你愿意，我下一步就继续直接往 105 的同步来源 和 104 的失效点 深挖。 user: 可以，继续 assistant: 我继续查 104 / 105 两边的对象和日志，尽量把“105是怎么来的、104为什么断了”锁具体。 assistant: reply_to_current 继续查出来了，这次基本把方向锁住了。

结论先说

105 之所以能全量有供应商，不是靠 `zhc_Ven_Ins`，而是极大概率走了 SQL Server 复制（Replication）这条链路。

104 缺失这 16 个供应商，也更像是：104 没有接上这条复制链，或者 104 的供应商表没有被复制覆盖，只依赖老的 `zhc_Ven_Ins`，而这条老触发器又失效/停用了。

我查到的关键证据

1）105 / 104 库里都有一组 sp_MS* 过程

我在 105 和 104 都查到了这些对象：

  • sp_MSins_dboVendor
  • sp_MSupd_dboVendor
  • sp_MSdel_dboVendor
  • sp_MSins_dboVendorBank
  • sp_MSupd_dboVendorBank
  • sp_MSdel_dboVendorBank
  • sp_MSins_dboVen_Contact
  • sp_MSupd_dboVen_Contact
  • sp_MSdel_dboVen_Contact

这组 sp_MS... 名字很典型，就是 SQL Server 事务复制/订阅端 常见的系统生成过程。

2）我把 105 的 sp_MSins_dboVendor 正文读出来了

它本质就是一个“把传入字段直接插到本地 Vendor 表”的过程：

sql
create procedure [dbo].[sp_MSins_dboVendor]
...
insert into [dbo].[Vendor](...)
values(...)

这基本就是复制订阅端接收上游数据时用的过程。 这不是你们手写业务触发器的命名风格，而是复制机制的典型痕迹。

3）105 库本身没有看到 Vendor 上的自定义同步触发器

我查 105 的触发器时，没看到 `Vendor` / `Ven_Contact` 上有 `zhc_Ven_Ins` / `zhc_Ven_Con_Ins` 这类自定义跨库同步触发器。

只看到：

  • EF_BaseInformation_P_Department
  • EF_BaseInformation_P_Inventory
  • EF_BaseInformation_P_Person

但没有 `EF_BaseInformation_P_Vendor` 之外的“101→105 跨库同步触发器”，而且没有你在 101 里看到的 zhc_Ven_Ins 那种写死 UFDATA_105_2019..Vendor 的逻辑。

这进一步支持：

105 的供应商，不是靠老触发器推过去的，而是靠复制机制同步过去的。

4）104 侧看到的情况

104 库里有：

  • EF_BaseInformation_P_Vendor（启用）
  • 也有复制相关的 sp_MS...Vendor... 过程

但实际数据上，104 缺了 16 条，而 105 一条没缺。

这说明最可能是：

情况A：105 参与了有效复制，104 没有正常接收 Vendor 复制

也就是：

  • 105 的供应商表接在复制链上，所以全量有
  • 104 没有真正跟上这条复制链，仍靠老触发器补
  • 老触发器失效后，104 就开始漏

情况B：104 也有复制对象，但该发布/订阅没有覆盖 Vendor，或者已停

也就是说：

  • sp_MS... 对象存在，不代表当前还在工作
  • 105 的复制是活的
  • 104 的复制可能只是历史残留对象

现在能解释你看到的矛盾了

你前面说：

负责同步供应商信息的触发器被禁用了？但是105数据库里面有这个供应商信息

现在答案就是：

对，二者并不矛盾。

因为：

  • 104 依赖的是老的自定义触发器同步，或者至少部分依赖它
  • 105 走的是另一条机制，极大概率是 SQL Server 复制
  • 所以即使 zhc_Ven_Ins 被禁用，105 仍然可以有数据
  • 但 104 会开始漏数据

关于“101账号里多少供应商没同步到104和105”

最终确认：

  • 101 总供应商：1459
  • 没同步到 104：16
  • 没同步到 105：0
  • 同时没同步到 104 和 105：0

所以异常完全聚焦在 104。

目前最靠谱的整体判断

105：

  • 供应商全量存在
  • 有复制落地过程 sp_MSins_dboVendor / sp_MSupd_dboVendor
  • 大概率由 SQL Server 复制维护

104：

  • 供应商缺 16 条
  • 101 里老触发器 zhc_Ven_Ins 明确写了 104 的同步 SQL
  • 但这条老链路现在失效/被禁用
  • 104 很可能没有被同样的复制链路稳定覆盖

下一步最值的两件事

如果你要彻底坐实，我建议继续查：

1）查 104 / 105 的复制元数据

确认：

  • 哪个库是发布库
  • 哪个库是订阅库
  • Vendor / VendorBank / Ven_Contact 是否在复制文章里

2）查 104 这 16 条是否从某个日期开始统一漏

如果能证明从某一天起全部“只漏104不漏105”，那就几乎能直接判定：

  • 104 的供应商同步链在那个时点中断了

如果你同意，我下一步就继续查复制元数据，把：

  • 105 是否真的是复制订阅端
  • 104 是否没订阅 Vendor / 或订阅失效

这件事直接坐实。 user: 可以，继续 assistant: 我继续查复制元数据，看看 104/105 的 Vendor 表到底是不是在复制链里。 assistant: reply_to_current 查实了，这次可以下结论了。

最终技术结论

1）UFDATA_101_2018 确实发布了供应商复制

在 101 库 我查到两个发布：

  • customer_autosyn
  • `vendor_autosyn`

而且 vendor_autosyn 发布的文章就是：

  • Ven_Contact
  • Vendor
  • VendorBank

也就是说：

101 是供应商主数据发布库。

2）104 和 105 都是 vendor_autosyn 的订阅端

在 104 和 105 库里，都查到了：

  • 发布者：U8SRVN
  • 发布库：UFDATA_101_2018
  • 发布名：vendor_autosyn
  • 复制对象：sp_MSins_dboVendor / sp_MSupd_dboVendor / sp_MSdel_dboVendor

这说明：

104 和 105 的 Vendor 表，理论上都应该从 101 复制过来。

所以现在不是“105 走复制、104 不走复制”，而是：

104 和 105 都走复制。

3）关键差异找到了：104 的 vendor 订阅坏了，105 的是正常的

我查了两边的 MSsubscription_agents：

105 的 vendor_autosyn

  • last_sync_status = 1
  • last_sync_summary = 同步正在进行中

这说明 105 的供应商复制是正常在线的。

104 的 vendor_autosyn

  • last_sync_status = 6
  • last_sync_summary = 已将此(这些)订阅标记为不活动，必须将其重新初始化。需要删除 NoSync 订阅，然后重新创建它们。

这句已经很明确了，意思就是：

104 的供应商复制订阅已经失效/不活动，需要重新初始化。

这就把你前面所有现象解释通了

为什么 105 有 081003？

因为 105 的 `vendor_autosyn` 正常运行，所以 101 新增的供应商能同步进去。

为什么 104 没有 081003？

因为 104 的 `vendor_autosyn` 已经坏了/失效了，所以后面新增的供应商没有继续同步进去。

为什么不止 081003 一个，而是 16 个？

因为这不是单条数据问题，而是：

104 的供应商复制链从 2026-03-08 开始就已经异常了。

这和我们前面统计出来的 16 条缺失时间段是对得上的。

你现在可以把原因定性为

UFDATA_104_2018 的供应商复制订阅失效，导致 101 → 104 的 Vendor / VendorBank / Ven_Contact 从 2026-03 起持续漏同步。

而不是：

  • 不是 081003 数据有问题
  • 不是 104 表结构不兼容
  • 也不是 105 手工补的

对应到你关心的 081003

供应商编码 081003 没同步到 104 的直接原因就是：

104 数据库的 `vendor_autosyn` 订阅已被标记为不活动，需要重新初始化，所以 101 中新增/修改的供应商主档没有再同步到 104。

补充：老触发器 zhc_Ven_Ins

这个触发器虽然也写了同步到 104 的 SQL，但从现在的证据看，真正主链路是复制 `vendor_autosyn`。 而且 104 当前的复制已经报错失效，所以缺失才会成批出现。

换句话说：

  • zhc_Ven_Ins 更像早期/补充方案
  • 现在实际依赖的是复制
  • 104 的复制坏了，才是主因

修复建议

方案A：修复复制链路（根本方案）

让数据库管理员处理 104 的 `vendor_autosyn` 订阅重新初始化。

根据系统提示，方向就是：

  1. 删除失效的 NoSync 订阅
  2. 重新创建 / 重新初始化 104 的 vendor_autosyn
  3. 重跑快照或重新同步

方案B：先手工补缺失 16 个供应商（应急方案）

在修复制前，先把这 16 个从 101 补到 104：

  • Vendor
  • VendorBank
  • Ven_Contact

这样业务先恢复。

现在手上已经确认的数据

  • 101 总供应商：1459
  • 没同步到 104：16
  • 没同步到 105：0
  • 104 的 vendor_autosyn：失效，需重新初始化
  • 105 的 vendor_autosyn：正常

如果你愿意，我下一步可以直接帮你做两件事中的任意一个：

  1. 输出这 16 个未同步到 104 的完整清单
  2. 生成一份把这 16 个供应商从 101 补到 104 的 SQL

user: 先按照“方案A：修复复制链路”来教我操作 assistant: reply_to_current 可以，按最稳妥的方式来。

你这个问题本质上是：

`UFDATA_104_2018` 的订阅 `vendor_autosyn` 已失效，需要重新初始化。

我建议你让 SQL Server 管理员 / 有复制权限的人 操作。 下面我先按 SSMS 图形界面方案 教你，最不容易出错。

一、先确认现状

先在 104 库 执行这条，确认订阅确实坏了：

sql
USE UFDATA_104_2018;
GO

SELECT *
FROM dbo.MSsubscription_agents
WHERE publication = 'vendor_autosyn';

你应该会看到类似：

  • last_sync_status = 6
  • last_sync_summary 提示：

已将此(这些)订阅标记为不活动，必须将其重新初始化。需要删除 NoSync 订阅，然后重新创建它们。

二、推荐做法：在 SSMS 里重建 104 的供应商订阅

第1步：先备份 / 记录现状

先记下这几个信息：

  • 发布服务器：U8SRVN
  • 发布数据库：UFDATA_101_2018
  • 发布名：vendor_autosyn
  • 目标订阅库：UFDATA_104_2018

最好先对 104 库做一次备份。

第2步：打开复制配置

在 SSMS 里连接发布服务器 U8SRVN，然后：

路径

复制 → 本地发布 → UFDATA_101_2018: vendor_autosyn

右键这个发布，看：

  • 查看快照代理状态
  • 查看日志读取器代理状态
  • 查看所有订阅

重点找订阅列表里有没有：

  • 订阅库：UFDATA_104_2018

第3步：删除 104 的坏订阅

在 vendor_autosyn 的订阅列表中：

找到目标库 `UFDATA_104_2018` 对应的订阅，右键：

  • 删除
  • 或 Delete Subscription
这里只删除 104 这一个坏订阅，不要误删 105 的正常订阅。

第4步：重新创建 104 订阅

对 vendor_autosyn 右键：

  • 新建订阅

然后按下面填：

关键参数

  • 发布：vendor_autosyn
  • 订阅服务器：当前这台实例（如果 104 在同实例）
  • 订阅数据库：UFDATA_104_2018
  • 代理位置：通常选 在分发服务器运行所有代理
  • 同步方式：立即同步 / 初始化
  • 初始化来源：快照
  • 代理账户：用原来复制代理能跑通的账户

如果有选项：

  • Initialize subscription immediately：选上
  • Create a snapshot immediately：建议选上

第5步：重新生成快照

如果系统没自动生成，就在发布 vendor_autosyn 上右键：

  • 启动快照代理
  • 或 重新生成快照

等快照生成完成。

第6步：启动分发代理 / 同步

再对 UFDATA_104_2018 这条订阅：

  • 查看同步状态
  • 启动同步

正常的话，Vendor / VendorBank / Ven_Contact 会重新同步到 104。

三、同步完成后怎么验证

先查订阅状态：

sql
USE UFDATA_104_2018;
GO

SELECT *
FROM dbo.MSsubscription_agents
WHERE publication = 'vendor_autosyn';

正常应接近：

  • last_sync_status = 1

再查缺失供应商，比如你关心的 081003：

sql
SELECT *
FROM UFDATA_104_2018..Vendor
WHERE cVenCode = '081003';

再查总缺失数：

sql
SELECT COUNT(*) AS missing_104
FROM UFDATA_101_2018..Vendor v
WHERE NOT EXISTS (
    SELECT 1
    FROM UFDATA_104_2018..Vendor t
    WHERE t.cVenCode = v.cVenCode
);

如果修好，这个数量应该从 16 降到 0。

四、如果你想用 SQL 命令方式

一般也可以，但复制对象比较敏感，我更建议你先走 SSMS。 因为 SQL 方式涉及：

  • 删除订阅
  • 重新添加订阅
  • 重新初始化
  • 重新跑快照

一旦参数写错，容易误伤别的订阅。

五、操作时一定注意

  1. 只动 `UFDATA_104_2018` 这条订阅
  2. 不要动 `UFDATA_105_2019`
  • 105 现在是正常的
  1. 最好安排在业务低峰
  2. 如果 104 里已经有人工补录数据，要先确认是否允许被复制覆盖

六、我建议你的实际执行顺序

最稳妥就是这 6 步：

  1. 备份 UFDATA_104_2018
  2. 在 SSMS 中找到发布 vendor_autosyn
  3. 删除 UFDATA_104_2018 的坏订阅
  4. 重新创建 UFDATA_104_2018 订阅
  5. 生成快照并启动同步
  6. 用 081003 和缺失数 16 做校验

如果你愿意，我下一条可以继续直接给你：

“SSMS 里每一步具体点哪里”的更细版操作说明 或者 一套 DBA 可执行的 T-SQL 重建订阅脚本模板。 user: ok，均已完成 assistant: reply_to_current 好，修复已经生效了。

我刚帮你复核到：

  • vendor_autosyn 在 104 的状态已经变成

`last_sync_status = 1`

  • last_sync_summary = 同步正在进行中
  • 最近同步时间：2026-05-14 11:04:50

这说明：

104 的供应商复制链已经恢复正常。

不过我这次查询结果里，后面两段校验 SQL 没完整返回出来，所以我建议你现在再补跑下面这两条，做最终验收。

1）查 101 还有多少供应商没同步到 104

sql
SELECT COUNT(*) AS missing_104
FROM UFDATA_101_2018..Vendor v
WHERE NOT EXISTS (
    SELECT 1
    FROM UFDATA_104_2018..Vendor t
    WHERE t.cVenCode = v.cVenCode
);

如果恢复彻底，结果应该是：

sql
missing_104 = 0

2）查你刚才关心的供应商是否已经补齐

sql
SELECT cVenCode, cVenName, dModifyDate
FROM UFDATA_104_2018..Vendor
WHERE cVenCode IN ('081003','081004','08964','08963');

正常的话，这几条现在都应该能查到了。

当前结论

目前可以确认的是：

  • 复制订阅故障已修复
  • 104 已重新接上 `vendor_autosyn`
  • 之前“101 有、105 有、104 没有”的根因已经解除

如果你愿意，我下一步可以直接继续帮你查：

  1. 这 16 条是否已经全部补到 104
  2. `VendorBank` 和 `Ven_Contact` 是否也一起补齐了

你只要回我一句：

继续核对全部补齐情况

我就直接帮你查完。