在源代码方面，您可能需要检查" syscolumns"。" status"列中所涉及的表+列。

状态列的位0-2指示该列的文本/图像类型的复制状态。

请在两个表中比较正常和不正常的情况。

HTH

Avinash

在所有情况下，状态值均为0，这在进行数据库复制时应该是正确的。

不同服务器中的my_db有3个"版本"：

-设置服务器
-迁移服务器
-生产服务器

首先将数据库从setup_server复制到migration_server，
然后在添加数据之后，将数据库从migration_server复制到production_server。

然后添加复制。

今天，我创建了第二个数据库copy_db，并将setup_server的转储装载到该数据库中，并将其添加到复制系统中。 内容列已正确复制。

然后，我将migration_server中的数据库转储加载到copy_db中，再次设置复制，并且content列的复制也很好。

最后，我在production_server上转储了my_db并转储到copy_db中，设置了复制，并且没有复制content列。

我还删除了repserver并从头开始安装它们。 问题仍然存在...

当您说" 已删除repserver并从头开始安装"时，表示您从全新的RS开始/RSSD对，或者您是否（重新）使用了相同的RS/RSSD对，并刚刚发出" drop sub/repdef "，随后发出了" create repdef/sub " 是同一对RS/RSSD吗？

我假设是前者，但是如果是后者，那么我想知道RSSD中是否有未清除的东西。

- --------------------------------

由于新表无法解决问题 我想知道这是否是一个具有"旧"设置/配置的"旧"表，从而导致repagent出现不兼容问题； 该 content 列的特定实例的历史是什么？

-该列最初创建为" off row"，后来更改为" in row"吗？

-该表是在15.7之前的ASE版本中创建的，如果是，是否在 content 列中标记了" use_index "？ （ sp_helpindex 是否在 content 列上显示索引？）

----------------- -----------------

对于将生产服务器复制到copy_db的测试，想知道是否尝试过：

-drop/重新配置repagent，然后测试复制？

-取消标记/标记db/tables/columns，然后测试复制？

如果这些方法之一有效，则可能会将焦点转移到 问题正在发生……与repagent有关……与db/table/column标记有关……

Hi Mark，

我的意思是从全新的RS/RSSD对开始

15.7服务器是从头开始启动的，它不是升级的系统。

我不确定从一开始是否是行内文本列，这是由同时离开公司的同事设置的。

--------

要将生产服务器复制到copy_db中，我首先在转储/加载之前删除了复制，以便原始数据库没有rep代理

除了sp_reptostandby copy_db'all'之外，我没有取消任何标记。

在周末期间，我有一个时间窗为自己安装服务器。 我转储了production_db，以便可以在测试后恢复它。

然后，我执行的操作与数据库最初获得内容的方式相同：将数据库转储到迁移服务器上，然后将其加载到生产服务器中（使用原始数据库，以便我确定问题出在 与数据库名称无关），设置复制和正确复制了内容列。

此服务器将于下周末投入生产，因此看来我们不会再遇到相同的问题。

我可以处理这个特定问题，但是如果content列允许为空，我们甚至都不会注意到它。 所以我希望找到这种"腐败"的原因。

谢谢

Luc。