Поведение запроса Weird OpenEdge

Question

Нам недавно пришлось выполнить некоторую работу с базой данных OpenEdge, которую использует сторонний продукт, а сегодня (после многократного вытягивания волос) мы наконец определили, почему представление не возвращало никаких результатов. Это рассматриваемое представление объединяет около 100 отдельных таблиц, а затем запрашивается (у нас ограниченные права на эту базу данных). Одно из полей, возвращаемые этой точки зрения является жестко строковый литерал, вдоль линий

'John Smith' AS TheName 

У нас были трудности, выполнение запросов, которые включали эту строку, которую мы пытались RTrim (вид вернулся много конечных пробелов), а затем объединяться с другим полем. Однако, если мы использовали RTrim в этом поле, вместо того, чтобы возвращать сообщение об ошибке или null или что-то подобное, строка просто не была возвращена. Мы не пытались использовать его в предложении WHERE или JOIN, это было просто частью SELECT ... FROM VIEWNAME. Просмотрев представление, казалось, что представление ошибочно обнаружило длину строки как 9 символов (в определении не было указана длина), и RTrim просто не работал. Теперь я понял, почему это может привести к сообщению об ошибке или значению NULL в SELECT, но . Почему строка просто не будет возвращена вообще? Это не похоже на хорошее поведение SQL, и я никогда не видел, чтобы это происходило с любыми другими СУБД.

Дополнительная информация: мы тестируем запросы через ODBC и WinSQL, чтобы это было включено в существующее приложение ASP.NET. У нас нет доступа к бэкэнд, кроме как через это, хотя у нас есть права на создание просмотров.

Обновление: Как неожиданное наблюдение, мы обнаружили, что если мы попытаемся запросить это представление без предложения WHERE, записи не будут возвращены. Это может иметь ту же причину.

Answer 1

Похоже, что это может быть связано с SQL-WIDTH в базе данных прогресса. Одна из проблем с Прогрессом заключается в том, что если содержимое поля превышает SQL-WIDTH, тогда вы получите странное поведение SQL (иногда драйвер может терпеть неудачу, в противном случае вы не получите никаких результатов).

Чтобы определить это, вам необходимо использовать команду dbtool для проверки превышения SQL-WIDTH.

Answer 2

Это звучит как очень странное поведение. Просто создайте код вокруг него, выполните обработку обрезки и/или строки в приложении и продолжайте свой путь.

Answer 3

Убедитесь, что у вас нет пробелов. Обрезка не удаляет пробелы только в пробелах. Заготовки также не являются нулями. Существует разница в наборе символов, в то время как в вашем редакторе это не заметно заметно. Я столкнулся с этим несколькими базами данных, DBII, Oracle, PostGreSQL. Проверьте набор символов вашего редактора и попробуйте просмотреть таблицы, вы ничего не увидите или увидите большие прямоугольники.