Аспид
"Хочу автоматом дозаполнять грид"
Это делал Sawradym может поделится кодом.

Я, кстати, не очень уверен, что все работает именно так как я написал, а проверить, честно говоря, до этого момента даже мысли не возникало. Да и сейчас сниферить особо большого желания нет.
В основе решения о котором я говорил лежит возможность доставать данные из адодибишного рекордсета по мере их надобности. В моем понимании данные тянутся на клиента порциями по FetchSize записей, вот цитата из оракловского мануала:

Цитата:

FetchSize - specifies the number of rows the provider will fetch at a time (fetch array). It must be set on the basis of data size and the response time of the network. If the value is set too high, then this could result in more wait time during the execution of the query. If the value is set too low, then this could result in many more round trips to the database. Valid values are 1 to 429,496, and 296. The default is 100.

Дальше все просто. У меня в КА есть метод CursorFetch который достает из рекордсета очередную порцию записей. Для начала вызов CursorFetch можно вставить в AfterRowColChange с условием что в локальном курсоре, который подвязан к рекордсету, мы достигли EOF.

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

Sawradym
В основе решения о котором я говорил лежит возможность доставать данные из адодибишного рекордсета по мере их надобности. В моем понимании данные тянутся на клиента порциями по FetchSize записей

FetchSize в adodb так же как и в самом фоксе определяет лишь размер порции данных вынимаемых за 1 обращение к серверу, но никак не говорит о том, что после извлечения первой порции необходимо остановиться. Так что поздравляю - ты извлекаешь именно ВСЕ записи подпадающие под условие При том я не вижу никакой необходимости хоть что-то ещё делать вручную.
FetchSize работает и для ODBC источников данных - при этом "сам по себе" он именно включает "прогрессивную выборку" - т.е. если оставить всё по умолчанию, т.е. FetchSize=100 то фокс будет изклекать данные порциями по 100 записей, но НЕ будет останавливать процесс извлечения после получения первой пачки - зато эта первая пачка будет отображаться в гриде/бровзе гораздо быстрее чем если отключить прогрессивную выборку присвоив свойству -1, и дожидаться извлечения полного набора записей (кстати, если не гасить нотификации, то в статусной строке будет видно как фокс докачивает всё оставшееся при уже видимой первой порции).
В фоксе есть ещё свойство FetchAsNeeded, которое включает ИМЕННО режим "подкачки по запросу" - т.е. извлечение данных с сервера остановится после того как будут вынуты эти самые 100 запией (на самом деле фокс извлечёт столько записей, сколько надо чтобы заполнить видимую часть грида, но кратно значению FetchSize - т.е. если FetchSize=100 и мы прокрутим грид так что в нём уже должны будут показываться 101-120 записи, то он вынимет все записи до 200-й).
Вся соль в том, что "недокачанный" курсор (что в первом, что во втором случае) создаёт гигантскую кучу проблем - например он занимает соединение (конечно если оно разделяемое, а не по отдельному соединению на каждый курсор - за что вообще-то DBA должен руки оторвать разрабу), и попытка вынуть какие-то другие записи (открыть другой курсор) завершится ошибкой "занятого соединений". Кроме того в таком "неполном" курсоре невозможно проводить модификацию записей - до тех пор пока он полностью не заполнится. Можно ли обойти эти проблемы - ну конечно же можно - хотя кода потребуется прилично, да и DBA гарантированно будет недоволен "висящими" на половине извлечения соединениями. Поэтому на практике я никогда таких решений не делал, да и у других крайне редко встречал - потому и не советую.

Аспид
Кнопки "вверх"- "вниз" вообще что то из доса.

Нет, это вполне штатный подход называемый paging. То что сейчас на вебе делают с автоподгрузкой при прокрутке основано на том же самом paging-е, просто без явных кнопок/ссылок "далее/назад" или кнопок/ссылок с номерами страниц. При этом с точки зрения БД это гораздо лучше чем полуподвисшее соединение получающееся в случае фоксового FetchAsNeeded, т.к. БД получает запрос и ПОЛНОСТЬЮ его отрабатывает, возвращая результат целиком (бэкэнд приложению как правило, не напрямую веб-странице). Реализуется это специальными конструкциями, специфичными для каждой отдельной СУБД - скажем Limit в mysql, OFFSET и FETCH NEXT в свежих MSSQL, подзапросах с row_number в оракле.

Да в принципе невозможно сделать "правильно" (за что ратует Сфинкс, и все остальные). например: БД - вся РФ, все ФИО. Вы запрашиваете "Иванов". Что вам показать в ответ? Первых 100 Ивановых? С возможностью динамической подгрузки следующих 100? А накуа?

Явно, что ответ зависит от задачи. Например юзер захотел просто посчитать всех жителей по фамилии Иванов, тогда надо ему дать для этого специальную кнопку. Но не стоит большого кода с динамической подгрузкой...

ПС. Делается как обычно, а именно как придется. Если приложить художественное воображение, то, возможно, есть красивый дизайнерский ход, в ходе которого естественно окажется, что "вам это не нужно", а может и нет )

Igor Korolyov
FetchSize в adodb так же как и в самом фоксе определяет лишь размер порции данных вынимаемых за 1 обращение к серверу,
но никак не говорит о том, что после извлечения первой порции необходимо остановиться. Так что поздравляю - ты извлекаешь
именно ВСЕ записи подпадающие под условие При том я не вижу никакой необходимости хоть что-то ещё делать вручную.

Спасибо за поздравления, но я таки не поленился и постаил CommView. Результат подтвердил мои догадки.

Igor Korolyov
FetchSize работает и для ODBC источников данных - при этом "сам по себе" он именно включает "прогрессивную выборку" -
т.е. если оставить всё по умолчанию, т.е. FetchSize=100 то фокс будет изклекать данные порциями по 100 записей,
но НЕ будет останавливать процесс извлечения после получения первой пачки - зато эта первая пачка будет отображаться
в гриде/бровзе гораздо быстрее чем если отключить прогрессивную выборку присвоив свойству -1, и дожидаться извлечения
полного набора записей (кстати, если не гасить нотификации, то в статусной строке будет видно как фокс докачивает всё
оставшееся при уже видимой первой порции).

Именно так все работает в случае odbc. В случае adodb все точно так же, но немножечко не так.
Данные действительно тянутся с сервера порциями кратными FetchSize, но при этом только те, которые будут реально затребованы
из рекордсета. Т.е. из многомиллионной выборки на клиента будут вытащены только те записи, которые упорный юзер наскролит
в своем гриде. При этом двнные будут подтягиваться по ходу процесса. Обычно пользователь открыв форму с гридом сразу же
настраивает фильтр. Это означает что в "холостую" на клиента будет вытащено только 50 записей (на данный момент мы
остановились на FetchSize=50). Через интернет все работает довольно живенько.

Igor Korolyov
В фоксе есть ещё свойство FetchAsNeeded, которое включает ИМЕННО режим "подкачки по запросу" - т.е. извлечение данных с
сервера остановится после того как будут вынуты эти самые 100 запией (на самом деле фокс извлечёт столько записей,
сколько надо чтобы заполнить видимую часть грида, но кратно значению FetchSize - т.е. если FetchSize=100 и мы прокрутим
грид так что в нём уже должны будут показываться 101-120 записи, то он вынимет все записи до 200-й).
Вся соль в том, что "недокачанный" курсор (что в первом, что во втором случае) создаёт гигантскую кучу проблем - например
он занимает соединение (конечно если оно разделяемое, а не по отдельному соединению на каждый курсор - за что вообще-то
DBA должен руки оторвать разрабу), и попытка вынуть какие-то другие записи (открыть другой курсор) завершится ошибкой
"занятого соединений". Кроме того в таком "неполном" курсоре невозможно проводить модификацию записей - до тех пор пока
он полностью не заполнится. Можно ли обойти эти проблемы - ну конечно же можно - хотя кода потребуется прилично, да и DBA
гарантированно будет недоволен "висящими" на половине извлечения соединениями. Поэтому на практике я никогда таких решений
не делал, да и у других крайне редко встречал - потому и не советую.

Опять же все вышеописанное справедливо для одбс. С адодб все по другому. Я могу держать хоть сотню открытых рекордсетов
и при этом они абсолютно независимы и друг другу не мешают. И да, все они используют одно-единственное шаред соединение.

С адодб может быть "по другому" только в том случае, если все эти recordset-ы НЕ конвертируются в фоксовые курсоры курсорадаптером (это возможно, но работа именно с рекордсетом в фоксе крайне неудобна - штатный грид к примеру такой источник данных не возьмёт, а активиксовый использовать - ну как то тяжеловесно). Иначе фокс запросит из рекордсета в курсор все данные (конечно же если его не настраивать на работу "выборка по требованию").
Как разделяют адошное соединение адошные же рекордсеты я не в курсе - возможно что они и "не мешают" друг другу. В своё время скорость работы и накладные расходы на вариант с АДОДБ лично мне показались неприемлемо высокими, и мы так не работали.

Совершенно верно. Для этого специально был написан свой аналог курсорадаптера, который и занимантся вытаскиванием данных из рекордсета в фоксовый курсор, плюс еще кое чем по мелочам. Нативный КА в режиме adodb сделан видимо только для демонстрации наличия такой возможности, ибо даже для передачи параметров все равно придется городить целый огород, так как в данном случае не достаточно просто насоздавать переменных их нужно затолкнуть в специальнкю коллекцию.

Когда-то очень давно я смотрел библиотеку для "прямого" использования oledb провайдеров в фоксе (вроде как fll такая с функциями а-ля SQLEXEC но для OLEDB провайдера) - без прослойки ADO. По идее это давало бы очень неплохую скорость и минимальные издержки в потребляемой памяти (это было бы почти как ODBC-ный доступ) - но проект, насколько я помню, так никогда и не был доведен до конца. И да, это было ещё до появления курсорадаптеров А в курсорадаптерах MS сильно схалтурил - вместо, опять же, прямого подключения провайдера к фоксовому движку они тоже ходят через горбатые мосты ADODB со всеми его тоннами COM-объектов и не самой лучшей интеграцией.

А использовать почти курсорный движок ADO совместно с курсорным движком фокса, тем более в "ручном" режиме перегоняя данные между этими "курсорами" - не, на такое я бы даже под пытками не пошёл

sphinx

PaulWist
используй фильтр ТОЛЬКО на сервере, таким образом задача упроститься в 2 раза

Да я бы рад использовать... Знать бы, как правильно. Ты тоже не кинешься примером?

Ну вот выяснилось, ты хочешь динамическую подкачку данных, предлагаю на первом этапе отказаться от неё (про connection busy уже написали + придётся делать СОМ-сервер для подкачки), тогда задача упрощается до формы фильтра и разбора что в фильтер ввели.

1. Структура данных фильтра и ХП вынимающая фильтр описана тут

2. Функции разбора того, что юзер в фильтре ввёл.

Умолчания:

2.1. Запятая в поле фильтра - это список значений, например Код документа: 123, 234, 345 будет выглядеть как [IN (123, 234, 345)]

2.2. Точка с запятой - это интервал, например Дата документа: 01.01.2019;01.20.2019 будет выглядеть как [between 01.01.2019 and 01.20.2019]

2.2. Звёздочка в начале поля фильтра, например тема Документа: *поставка, будет выглядеть как [like '%поставка%']
2.2.1. Без звёздочки в начале поля фильтра, например тема Документа: поставка, будет выглядеть как [like 'поставка%']

Igor Korolyov
Когда-то очень давно я смотрел библиотеку для "прямого" использования oledb провайдеров в фоксе (вроде как fll такая с функциями а-ля SQLEXEC но для OLEDB провайдера) - без прослойки ADO. По идее это давало бы очень неплохую скорость и минимальные издержки в потребляемой памяти (это было бы почти как ODBC-ный доступ) - но проект, насколько я помню, так никогда и не был доведен до конца. И да, это было ещё до появления курсорадаптеров А в курсорадаптерах MS сильно схалтурил - вместо, опять же, прямого подключения провайдера к фоксовому движку они тоже ходят через горбатые мосты ADODB со всеми его тоннами COM-объектов и не самой лучшей интеграцией.
А использовать почти курсорный движок ADO совместно с курсорным движком фокса, тем более в "ручном" режиме перегоняя данные между этими "курсорами" - не, на такое я бы даже под пытками не пошёл

Я никого не агитирую. Меня спросили, я ответил. Все что написано выше уважаю, но не разделяю.
Твердо уверен в том что плюшки полученные в результате использования adodb с лихвой компенсируют сложности в реализации.

Полученные "плюшки", а точнее единственная плюшка, это динамическая подгрузка в грид порций записей при листании. Как по мне, то это весьма сомнительный UX для большинства производственных систем. Да, для развлекательных он может быть и вполне себе ничего - листаешь помаленьку, читаешь чего пишут "в ленте". Почтовые или чат-системы - там тоже имеет смысл такого рода подгрузка (именно потому что ВСЯ предоставляемая информация по сути то и нужна - т.е. не про поиск уже идёт речь) - хотя редко там отлистывают историю на десятки и сотни "страниц".
Но для работы как правило требуется максимально быстро что-то найти - и тут никакие динамические подгрузки уже не требуются - не нашёл на первом экране - уточни критерии поиска, а не "листай" в надежде что оно на втором будет, или третьем, или 150-м Тем более что для фокса "страницей" вполне может служить и 1000 записей (не помрёт он от таких объёмов - да и сервер вполне справится за вполне разумное время) - это больше чем на полусотне страниц вывода гугла (вроде бы по умолчанию он по 10 результатов показывает), и как чья-нить вконтактная лента за пару лет
Чтобы понять о чём я, ответь на банальный вопрос - как часто при поиске в гугле ты долистываешь хотя бы до 10-й страницы

Igor Korolyov
Полученные "плюшки", а точнее единственная плюшка, это динамическая подгрузка в грид порций записей при листании.

Ну есть еще такая мелочь как отсутствие Connection Busy.

Igor Korolyov
Как по мне, то это весьма сомнительный UX для большинства производственных систем.
Да, для развлекательных он может быть и вполне себе ничего - листаешь помаленьку, читаешь чего пишут "в ленте". Почтовые или чат-системы - там тоже имеет смысл такого рода подгрузка (именно потому что ВСЯ предоставляемая информация по сути то и нужна - т.е. не про поиск уже идёт речь) - хотя редко там отлистывают историю на десятки и сотни "страниц".
Но для работы как правило требуется максимально быстро что-то найти - и тут никакие динамические подгрузки уже не требуются - не нашёл на первом экране - уточни критерии поиска, а не "листай" в надежде что оно на втором будет, или третьем, или 150-м Тем более что для фокса "страницей" вполне может служить и 1000 записей (не помрёт он от таких объёмов - да и сервер вполне справится за вполне разумное время) - это больше чем на полусотне страниц вывода гугла (вроде бы по умолчанию он по 10 результатов показывает), и как чья-нить вконтактная лента за пару лет

Я все-таки рассматриваю эту ситуацию немного по другому. В моем случае у пользователя есть выбор поступать как ему удобнее. Причем в разных ситуациях он может поступать по разному. Ты же агитируешь оставлять пользователю один-единственный путь, несомненно более правильный, но гораздо менее понятный и очевидный для юзера, особенно на этапе обучения.

Igor Korolyov
Чтобы понять о чём я, ответь на банальный вопрос - как часто при поиске в гугле ты долистываешь хотя бы до 10-й страницы

Эх, если бы все пользователи были такими как я ;)

Паш, спасибо большое. Пусть у нас не МС-СКЛ, но идею, думаю будут понятны. Не обещаю, что что-то на днях попробую сделать с такой подсказкой, но суть ты понял правильно, сформулировал корректнее. Да, именно это и надо. Мне нужна была ИДЕОЛОГИЯ, а не вопросы передачи параметров.

Еще раз спасибо. Ну и Володе и Сергею Сизову - ну простите меня, что немного раздувал. Не со зла же, понятно. Мне вполне достаточно, что Паша просто быстрее сообразил суть проблемы. Надеюсь, что его ссылка мне поможет, мне ведь пнуть надо, разжевать я и сам в состоянии, поди опыта и умений искать нужную информации вполне хватит. Ну, допускаю, что не всегда. Ибо не знаешь, что искать, собсно...



Отпишусь обязательно, что получилось, или нет. Или задам другие вопросы. Ребят, спасибо, реально!