постраничная загрузка Browse

[Andrew™]

после долгих дебат в ClaList'е я решил всё таки воспроизвести сие чудо на Source примере, на удивление моё, скорости загрузки при скроллингах меня поразили, одни и те же SELECT'ы через FILE,DRIVER и через MAV выполняются сокрушительно разно по скорости

так что встраиваю в Browse третий режим загрузки, переделывать много не придётся, появится просто доб объект - MAVPageLoader, который и будет следить в Browse за загрузкой при скроллингах

[Andrew™]

Реализовал я SUBJ, без ущемления текущего функционала, т е и сортировки понажатию на заголовки, поиски по текущему полю сортировки. Только надо понимать что постраничная загрузка неприемлема для деревянного Browse и для буфферных Browse (в формах редактирования), такие Browse должны грузиться целиком.

ещё не додумал с итоговыми полями, раз гружу страницу, значит для вычисления TOTAL надо выполнять доп запросы к БД, сейчас (пока что) итоговые поля работают только по данным в List Queue

только вот какая штука, ктороая имеет место быть и в постраничной Browse FILE,DRIVER, если имеет место сортировка по полю которому разрешён NULL и в БД есть такие записи с такими NULL полями то в Browse такие записи не попадают, если Выберем другую сортировку, то такие записи появляются, опять встаём на запись где есть поле это NULL, кликаем на List Header этой колонки - и в выборке ТОЛКО видны записи у которых такие поля NULL, пока что я сделал такое поведение загрузки.

ЗЫ
как поступать с обновлением пока не знаю, фича на мой взгляд полезная, которую я всегда считал непреемлемой для SQL, цену подымаю на библиотеку, для официальных пользователей считайте что это годовое тех. сопровожение продукта, кто приобрёл >= Май 2006 обновление бесплатно.

[Andrew™]

с итоговыми полями тоже разобрался, при загрузке Top/bottom генерится сответсвующий SQL капрос к БД

по поводу поиска по локаторному полю, тут как выяснилось имеет место быть следующее ограничение при работе с постраничной Browse.
Если мы грузим всё и сортируем всё на клиенте, то при поиске по локатору происходит поиск в List Queue, при постраничной, последовательность нахождения записей в List Queue очень важна чтобы правильно производить скороллирование, Т е сортировка в List Queue должна совпадать с ORDER BY, точнее к List Queue не применяется SORT, а т к вычисляемое поле (локальная переменная -столбей) нельзя засунуть в ORDER BY, то и поиски и сортировки по нему выключаются в такой Browse.

[Andrew™]

ещё, чтобы правильно работала Browse, как и в стандартной Browse ORDER BY должЁн быть по уникальному ключу, тут это тоже надо, но не надо об этом голову забивать, библа сама при необходимости добавляет поля первичного ключа к ORDER BY тем самым получая уникальную последовательность, а наличие Primary key обязательно, так что никаких проблем в использовании.

[ru_alex]

Всем привет!
Вопрос Андрею, правда несколько не в тему...
Как обрабатываешь случай, когда сортировка идет по строковым ключам, и значения сожержат, например, одинарную кавычку или несколько. При позиционировании на такой записи сформированный запрос будет вида

Код: Выделить всё

select A.Name, A.Id from dbo.File A where A.Name > 'qqq'qq' or (A.Name = 'qqq'qq'  and A.Id >= 1) order by  A.Name, A.Id

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