奇怪的是为什么它可以在其他PC上运行？

我想知道与您使用的数据源是否有关系？

可能需要更新数据库客户端...

Don

Don，

我得到的错误是"未指定的错误"。 我正在使用13.0.16.1954，但是我相信这在13.0.9中也是一个问题。 我没有收到使用13.0.5的人员的任何报告。

我在去年夏天遇到了这个问题，好几个星期都找不到解决方案。 我终于发现Number参数引起了问题。 转换为字符串，问题就消失了。 我实际上只是再次完成了测试，因为我在对应用程序进行Beta测试时遇到了它，却没有意识到我正在使用带有数字提示的rpt。 如果我传递值以提示用户，这似乎无关紧要，但仍然会收到错误。

我只是想在发现该线程的情况下会再次四处查看，以防万一还有其他解决方案或更新对其进行修复，但看起来它仍然是引擎的一部分。

安德斯，

SP 22刚刚发布，看看有什么区别。

我假设您也对3500个程序集进行了更新？

在这些Windows 7 PC上是否安装了所有Framework更新？

唐

好。 在这里回复我自己的帖子。 在三分之二的计算机上，以及从SP13升级到SP21之后，都会发生该错误。 受影响的计算机都是Windows 7，其运行的计算机是Windows 10。

如果从Crystal Reports 2013编辑器运行报表，则不会发生此问题。 仅当您通过我们的应用调用报告时才会发生

罪魁祸首是未从我们的应用程序传递的数字参数。 而是报告提示他们。 这些报告都是特定于客户的，并从仅提供默认参数的菜单提示中启动。 这样的"毒性"参数如下。 简单的解决方法是将所有这些更改为String参数并调整公式。

要触发该错误，所需要做的就是使参数存在并出现在页面上。 它不需要成为公式的一部分。

任何暗示为何会发生这种情况？

是的不要对程序集进行更新，因为如果没有的话，它们将不起作用。 我假设所有框架更新均已应用，因为我们使用的安装程序已将这些更新设置为先决条件。 我将这几个报告重新编码为使用字符串参数作为解决方法。 我将看看是否可以找到另一台Windows 7机器进行测试。

很高兴看到我并不孤单。.昨天又有另一个客户致电同一问题。 您是否从DEV收到任何回复，唐？ 同时，"所有框架更新"-标准Windows更新是否足够，还是我应该应用其他任何内容？