forum.clarionlife.net

C9.1 ABC, Firebird 2.1 через ODBC. Есть таблица с полем (столбцом), значения которого могут быть NULL. При сортировке броуза по этому столбцу все записи с "нулевыми" значениями не отображаются. Посмотрел классы, такое ощущение, что это принципиальный момент (не ошибка в классах). Что можно предпринять? Причём вот этот мой пример не показательный (можно NULL'ы заменить на 0 или пробел). Гораздо интересней когда идёт связка, скажем, двух таблиц по left outer join, и поля второй таблице может не быть железно.

А ключ, по которому строится броуз, допускает нули?

А ключа нет вообще. Я посмотрел, как Clarion создаёт запрос. Всё правильно создаёт, нужный столбец + первичный ключ. Но ключа в словаре такого нет. Я как нарвался на проблему? Включил сортировку в броузе по нажатию на header. И получил проблему в броузе, где есть пустые значения. Начал копать и делать тестовые варианты, и, оказалось, что это стандартное поведение. Я делаю броуз с сортировкой "No Key", но в "Additional Sort Fields" добавляю нужный столбец и первичный ключ (тоже одно поле). Результат плох. При первой загрузке броуза отображает всё, следующая загрузка записи с нулями не отображает. То ли буфер вьюхи так работает, то ли ещё что-нибудь. Повторю, что запрос на сервер идёт правильный.

Ага, натыкался на такое. Там кларион генерит некорректный запрос для позиционирования на запись. Частичного успеха достиг, переписав методы Next и Play для Browse - чтобы на границе Null-не Null и наоборот происходил корректный переход. Но только частичного - лёгкое движение и брюки превращаются...

Потом добавили фильтр - смотреть либо c Null либо без Null.

Next и Previous, конечно - оговорка по Фрейду, делал проигрывание сценария для обучащей программы...

Про баг/фичу понятно. Ну а если вернуться к мысли о ключе (см. реплику Деда Пахома) и описать его в словаре? Лучше не станет?

А там возникает деликатный вопрос - Null это меньше других значений или больше? У меня было больше...

Понятно, что деликатный, только сдаётся мне, что это может зависеть от СУБД, ведь при задании сортировки по ключу мы фактически передаём в драйвер БД предложение ORDER BY. А уж, что там СУБД вернёт, а главное, в какой сортировке, это её личные причуды.

Я в MS SQL добавил в таблицу вычисляемое поле (пробел если Null, дата в строковом виде в противном случае) и по нему построил индекс. Сработало. Правда стало ругаться в другом месте. Можно и так попробовать, если Interbase позволяет конечно...

Я ещё раз свою мысль повторю. Ситуация стандартная на всех связанных таблицах (по форейн ключу, вычисляемых). Eсли в связанной таблице нет значения, то запрос всё равно выдаёт null. Проблема, действительно, в баге, next по вьюхе лажает. И можно было бы в конкретном случае что-либо сделать, но проблема неприятна, когда разрешаешь сортировать по нажатия на заголовок столбца (работает стандартный класс). И самое правильное вот этот класс переписать. Особенно, если все записи уже выгружены в очередь. Надо подумать над этим, хотя, замечу, текущая реализация довольно приятна.

сколько связанных таблиц в VIEW? Я нарывался на непредсказуемое поведение драйвера odbc или VIEW (не знаю, кто виноват), если таблиц 3 и больше. Лечил кардинально, создавая VIew на сервере.

Тестовый пример на одной таблице уже не проходит. Если есть значения с NULL, то пипец. Вопрос в том, можно ли подправить конституцию за дёшево? Или это, как обычно, пиши свою обработку?

Задёшево - добавить в таблицу Computed-поле, добавить это новое поле в словарь со свойством Readonly. А уже по этому полю создать индекс.
В принципе, работает. Если повезёт, конечно....

Yufil писал(а):Задёшево - добавить в таблицу Computed-поле, добавить это новое поле в словарь со свойством Readonly. А уже по этому полю создать индекс.
В принципе, работает. Если повезёт, конечно....

С одной таблицей вопрос решаемый. Проблема в связке, например, двух.
Пример (может быть не слишком удачный, главное - принцип). Есть таблица сотрудников, и есть таблица специальностей, связанные по форейн ключу. Но поле-ссылка на таблицу специальностей в таблице сотрудников необязательное. Броуз по двум таблицам выглядит примерное так:
Иванов И.И., Инженер 1 категориии
Петров П.П., Инженер 2 категории
Сидоров С.С.,
Яковлев Я.Я., Рабочий.
Попытка сортировать по полю "Специальность" приводит к краху.
А "задёшево" я имел ввиду что-нибудь подправить в существующих ABC классах, не переписывая, к примеру, весь ViewManager. Наверно, много хочу. И проблема не в ABC классах.

Ну да, чтобы Browse крутилось, нужно, чтобы ключ был уникальный, для начала, а просто по полю "Специальность" не проканает,
поелику для сохранения и восстановления текущей строки используется Position, являющаяся в SQL, насколько я помню, просто конкатенацией ключевых полей. Например, Специальность-ФИО-код сотрудника.