Crystal reports 子报表失去了设计

我经历了一个严重的问题。。。我在过去两个月一直在编写的4份报告最近丢失了所有的子报告设计

相反，我现在看到的是，各子报告基本上恢复了原始设计，即大约2个月前的子报告设计

我完全被难住了。。。。任何想法。。。因为这是噩梦的素材

问题是，我决定不为每个主报表保存单独的子报表，以便更容易重用单个子报表模板。。。现在我很遗憾这不仅需要时间重新设计子报告。。。调试/验证子报表的准确性也需要时间

用例：我如何使用子报表如下： 1.有一个子报表模板实际存储在某处。 2.此子报表插入到每个单独的主报表中。 3.然后在相应主报告的“内部”修改此子报告。 4.根据经验，此修改不会影响仍保留其原始设计的原始子报表模板。 5.这些修改仍然存在于单独的主报告中。。。即使文件名实际上与原始子报表模板相同。 6.从经验来看，这是一种高效合理的工作方式。。。因此，我省去了将同一子报表的单独（但稍加修改）副本物理上专用于每个主报表的麻烦。 7.这似乎一直有效，直到灾难降临。。。没有任何解释或理由

注意：-我通常自己手动控制报表的版本，即，一旦我进行更改，我会保存同一主报表的不同物理版本。此差异版本存在于本地系统和单独的物理共享网络文件夹中。因此，这个问题不仅仅是文件被覆盖的情况

令人惊讶的是，当问题发生时，它影响了所有版本，无论它存储在哪里。。。这意味着这个问题非常根本

---

编辑：

这些报告现在又“全部”起作用了。。。但问题是，对于为什么它们最初“全部”恢复到子报表的旧设计，仍然没有任何解释

似乎我在主要报告之间共享单个子报告的方法（如前所述）并不稳定，因此是一种非常独特的做法。应该怀疑有些事情不太对劲，因为我过去也有过类似的经历，但。。。不知怎的，我觉得我做的不对

---

我现在已经开始为每个主报告指定一个特定的物理子报告（正如支持我的雇主Crystal report安装的公司所建议的那样）。。。因为我不再相信，一旦报表进入生产场景，我以前的方法将来仍然不会出现相同的行为。

子报表上是否启用了“打开时重新导入”？如果是这样，可能源子RPT文件被移动，CR因此无法打开它们，从而导致您所经历的情况

---

在我15年左右的工作时间里，我从未见过这种行为。是因为设计上的改变回到了2个月前的样子，还是因为数据的老化

如果您仍在从子报表获取数据，则它似乎仍在访问子报表，而不是您想要的版本。在crystal中，如果右键单击子报告并转到“编辑子报告”，请查看该文件是否正确，位置是否正确。还要检查是否打开的主报表的旧版本仍然指向子报表的旧版本

如果您没有从报告中获得任何信息，请检查子报告是否仍然存在并按预期运行，以及两个报告是否仍然包含链接字段

如果所有这些都失败了，检查你的电子邮件。我已经通过以前的版本或实例保存了几次文档，这些文档是我之前发送给别人的，在我发送的邮件中找到的

---

注意：我还是有点像水晶一样的傻瓜

刚刚检查确认了你的建议。。。所以“否”未选中“打开时重新导入”…当然，您使用的是版本控制工具，因此您可以检索最新的签入版本，或者无法从上次备份中恢复…？这只是设计，数据库中的数据仍然正确。我求助于根据记忆和笔记重新设计报告。即使是支持Crystal Report安装的公司也不知道会发生这种情况。我的使用方法似乎有点独特和高效。。。但可悲的是，从我的经验来看，情况并不稳定。因此，我现在又回到为每个主报告使用特定的物理子报告，而不是在多个主报告之间共享子报告。这显然效率不高，但似乎这是解决不稳定问题的唯一方法。虽然这是一次令人沮丧的经历，但我看不出这是一个更稳定的解决方案（而且肯定不是一个可扩展的解决方案）。我不确定有多少报告使用了这些子报告，但如果您有多个基本相同报告的副本，每次您要进行更改时，您都必须进行某种注册，以手动记住哪些报告使用了克隆文件以及它们的存储位置，每次你进行更新都必须是手动的。我过去经常这样做，后来改为共享子报表，这是一个救命稻草。它肯定是不可扩展的，因为它现在真的让我慢了下来。。。请注意，即使是@Craig也说他已经15年没有这样的经历了。2.我了解到，在SAP告诉我为什么共享子报告会导致噩梦般的体验之前，我别无选择，只能选择效率较低的路径。。。甚至我们的第三方支持