Sql 奇怪的OpenEdge查询行为

我们最近不得不使用一个第三方产品使用的OpenEdge数据库进行一些工作，今天（在做了大量的头发拉扯之后），我们终于确定了为什么视图没有返回结果。 这个视图合并了大约100个单独的表，然后根据这些表进行查询（我们对这个数据库的权限有限）。此视图返回的一个字段是硬编码的字符串文字，沿

'John Smith' AS TheName

我们在运行包含这个字符串的查询时遇到了困难，我们试图RTrim（视图返回了很多尾随空格），然后与另一个字段连接。 但是，如果我们在这个字段上使用RTrim，那么就不会返回错误消息或null之类的内容，而是不会返回行。我们没有试图在WHERE子句或JOIN中使用它，这只是SELECT的一部分。。。从VIEWNAME。查看视图后，视图似乎错误地检测到字符串的长度为9个字符（定义中没有指定长度），RTrim就是不起作用。 现在，我可以理解为什么这可能会导致错误消息或SELECT中的空值，但是为什么该行根本不会返回？这似乎不是一个好的SQL行为，我从未见过任何其他RDBMS出现这种情况

其他信息：我们正在通过ODBC和WinSQL进行测试查询，以期将其包含在现有ASP.NET应用程序中。除此之外，我们没有访问后端的权限，尽管我们有创建视图的权限

---

更新：作为一个奇怪的后续，我们现在发现，如果我们尝试在没有任何WHERE子句的情况下查询此视图，则不会返回任何记录。这可能有相同的原因。

听起来很奇怪。只需编写代码，在应用程序中执行修剪和/或字符串操作，然后继续操作。

确保没有空格。修剪不会删除空格，只删除空格。空格也不是空值。角色集存在差异，而编辑器中的差异不明显。

---

我在一些数据库中遇到过这种情况，比如DBII、Oracle、PostGreSQL。检查编辑器的字符集并尝试查看表格，您可能看不到任何内容或看到大矩形。

这听起来可能与进度数据库中的SQL-WIDTH有关。Progress的一个问题是，如果字段的内容超过了SQL-WIDTH，那么您将获得奇怪的SQL行为（有时驱动程序可能会失败，有时您不会得到任何结果）

---

要确定这一点，您需要使用

dbtool

命令检查可能超出的SQL-WIDTH。

读了一点之后，这听起来是导致这种行为的奇怪但似乎合理的原因。遗憾的是，我无法确定地测试它。您是否可以访问progress命令或progress DBA来验证宽度？Progress数据库本质上非常奇怪，它们的行为与其他传统SQL数据库不同。