В форме по вьюхе показываются не все строки

[Peppi]

Добрый день всем.
Столкнулись вот со следующей проблемой, причину которой не можем никак понять:

Есть форма, она работает по вьюхе (вьюха переопределенная в sql).
1. При выполнении запроса по всей вьюхе - показывается 10 строк, если нажать итоги - считает нужное количество - около 20000.

2. Начинаем фильтровать запрос - отрабатывает корректно и показвыает правильное количество строк (в том числе, если использовать расширенный фильтр или фильтр по сетке), но как только пытаемся фильтровать по группе, которая в итоге должна показать всё - снова эти 10 строк. Можно нажать упорядочить по полю - и тоже запрос отрабатывает, но остаются только 10 строк. (Видно, что данные изменились по условиям сортировки, но строк мало)

3. Проверяли в sql - вьюха корректная, показывает верное количество строк. Форму компилировали. Аос перегрузили.

Один раз такое было, но потом прошло само..

У кого-нибудь есть идеи, почему на форме отображаются не все строки? Может ли быть, что, начиная с какого-то объема данных, на форме не могут быть отражены все строки(в случае если это вьюха, например)?

[Peppi]

Хотела добавить, что раньше все работало, кроме одного раза, который, как я писала раньше, прошел сам.

[db]

при просмотре через в обозреватель таблиц то же 10 строк?
каким образом заполняются RecId в переопределенном представлении?

[Peppi]

"при просмотре через в обозреватель таблиц то же 10 строк"
Вообще не удается дождаться выполнения запроса. Так как в форме при открытии еще фильтр накладывается, а тут нет.

RecId заполняется значениями RecId основной таблицы вьюхи

[samolalex]

В памяти есть похожий случай, который встречался при связи LEFT JOIN: если значение поля в привязанной таблице равно NULL, тогда следует заменить его значение на 0 или символ пустой строки (не помню его код, но отображается как квадрат в кавычках) в зависимости от типа данных. Вот пример кода:

"CASE WHEN ИМЯ_ТАБЛИЦЫ.ИМЯ_ПОЛЯ IS NULL THEN 0 ELSE ИМЯ_ТАБЛИЦЫ.ИМЯ_ПОЛЯ END AS АЛИАС, \n"+

В PLSQLDeveloper'e действительно все отображалось в отличие от аксапты, плюс к этому не работала фильтрация по полям со значением NULL.

P.S. СУБД Oracle.

[samolalex]

Еще вариант:
Проверьте соответствие полей, по которым вы осуществляете связь.
В случае, если в ваших расширенных типах данных стоит свойство Alignment, например, равное "Right", то не исключено, что в Аксапте отступ будет заполнен пробелами, что в свою очередь может привести к нарушению связи, поэтому в sql-запросе лучше всего использовать функцию SUBSTR, пример кода:

"(SUBSTR(NLS_LOWER(ТАБЛИЦА1.ПОЛЕ_СВЯЗИ),1,20) = SUBSTR(NLS_LOWER(ТАБЛИЦА2.ПОЛЕ_СВЯЗИ),1,20)) \n"+

Кстати, важно не забыть про NLS_LOWER для приведения значений полей к нижнему регистру, что также поможет избежать несоответсвия полей.
Еще нужно отметить, что в Аксапте важна длина расширенных типов связываемых полей - если она будет разной, связь не сработает.

[Peppi]

К сожалению ли, к радости ли, заработало опять само...

Но я на всякий случай учла ваши рекомендации во вьюхе, надеюсь, ошибка повторяться не будет.
Спасибо за советы.

[db]

ну всё таки дождитесь лучше
RecId уникального я так понимаю нет?

Была похожая ситуация в 3.0 когда таблица (не вьюха) заполнялась средствами БД без уникального RecId. При этом был другой уникальный индекс был. Симптомы похожие - не видно некоторых записей в форме, после фильтрации и сортировки появлялись. Вылечилось шаманскими способами передвиганием столбцов в этом уникальном индексе, но вам это не подходит

Если значения в RecId не уникальные, то попробуйте все таки сделать их таковымы. Можно попробовать использовать для этого ROW_NUMBER() OVER (ORDER BY ...)