Добрый день всем гуру.

Продолжаю свою эпопею с юзанием GridMode режима у грида.
Совершенно запланировано столкнулся с проблемой позиционирования на гриде после перечитки запроса.
У меня реализован механизм выполнения запроса (сам запрос собирается динамически) с учетом пользовательских фильтров и сортировок. Все работает нормально, но есть нюансы. Один из них - после определенных действий вернуться на ту же запись в TableView. Заказчик хочет (и это вполне нормальное желание), чтобы после совершения действия, если набор данных не менялся, автоматом переходить на запись, с которой совершалось действие. И не просто переходить (в этом как раз проблемы нету), но чтобы на сетке сама запись оставалась на том же месте. Например, видимая часть TableView содержит 27 строк. Я стою на 20-й и хочу после совершения операции (которая вызывает перевыполнение запроса без изменений набора данных) снова видеть выделенной эту же строку на той же позиции в TableView. Вся проблема в том, что включен GridMode и параметры TopRowIndex и FocusedRowIndex зачастую отображают неверную информацию.
Почитал на форуме, но решения похожих проблем не нашел. Может у кого была такая же проблема, подскажите как выкрутиться из этой ситуации.
Заранее благодарю за дельные советы

JaDiЛеонов Юрий,

для начала надобно свою же собственную тему "закрыть", написав, чем всё закончилось и какое было решение:
http://www.sql.ru/forum/1304358/sortirovka-i-gridmode

Здесь решение еще не найдено, параллельно веду разработку. Поэтому писать пока нечего и закрывать соответственно рано

Фэйтл ЭраЛеонов Юрий...столкнулся с проблемой позиционирования на гриде после перечитки запроса.
...вернуться на ту же запись в TableView. Заказчик хочет..., чтобы после совершения действия, если набор данных не менялся, автоматом переходить на запись, с которой совершалось действие...

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

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

DimaBr1. Загружайте запрос в какой-нибудь мемори-датасет (TdxMemData), к нему и привязан Грид. (можно использовать и не DBView)
2. После редактирования записи отправляете данные на сервер
3. Если сервер вернул ошибку, то отменяете редактирование.
И не нужно перечитывать данные и менять положение курсора в Гриде.

Это немного не то, при ошибке перечитка не происходит

DimaBr,

Я выше написал, неправильно выразился. Данные меняются, но по полям, которые не участвуют в сортировке и фильтрации

Для наглядности вот 2 изображения. На первом состояние до выполнения действия

На втором - после совершения действия (проставили галочку)

У меня возможны несколько вариантов:
искомая запись улетает на самый верх;
отображает правильно, но фокус становится на предпоследнюю запись;
фокус может стоять вообще на неизвестной записи.

DimaBrЕсли вы не будите перечитывать данные, то всё останется на месте (если фильтры удовлетворяют условию)
Мне нужно перечитать эти данные, иначе как отобразятся изменения по действию

JaDi-guestTobVisibleIndex нужен или т.п. -- точно что-то есть.
Оно то есть, только совместно с GridMode=True не пашет

Фэйтл ЭраЛеонов Юрий,

зачем ты перечитываешь все данные? Ты что-то меняешь, кроме конкретной записи?
Нет, кроме конкретной не меняю, но изменения показать же нужно

DimaBrЛеонов ЮрийМне нужно перечитать эти данные, иначе как отобразятся изменения по действию
Вы изменяете строку датасета в памяти и отсылаете запрос на сервер. Если сервер вернул Добро, то заканчивается редактирование клиентского датасета. Изменяется всего одна строчка и никакие данные перечитывать не нужно. Если сервер вернул Ошибку, то отменяется редактирование и опять же данные перечитывать не нужно.

Вы вообще как редактируете данные ?
Редактирование осуществляется хранимой процедурой. Идет вызов, после которого обновление. На картинках частный случай, не стоит особо привязываться к ним

Virtual StudentТ.е. никто не рассматривает обычный DataSet.Locate('id', id, []) как вариант?
на второй картинке действие локейта. Они с первой отличаются?

Virtual StudentЛеонов Юрийпропущено...

на второй картинке действие локейта. Они с первой отличаются?
Остается только фокус переместить на нужную запись.

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

Фэйтл ЭраVirtual Studentпропущено...

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

Поставьте GridMode=True и вы поймете зачем. Не от хорошей жизни.

Если вы знаете правильный способ - поделитесь. Я же не утверждаю что изобрел новое колесо.

Фэйтл ЭраЛеонов Юрийфокус и так на нужной, сама строка улетела. Я понятно говорю или не поймете чего я хочу добиться?
"...когда я отрубаю петуху голову, он не поёт. Надо, чтобы пел."

Задрачивать и я умею. Вы мне ни одного дельного совета не дали, только фигней страдаете. Вы ответ на мой вопрос знаете? Так поделитесь. А если нет, то нечего флудить.

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

Задан был вопрос как перейти на запись и возобновить положение в сетке. Но тут уже скатились до того "а зачем переоткрывать"...
Значит надо, без лишней надобности не стал бы делать это

DimaBrВы редактируете данные хранимой процедурой. Она вам и возвращает ответ произошло редактирование(сохранение) или нет.
Логично предполагаю, что данные редактируются в не DB контролах.
Я же вам предлагаю отвязаный датасет в памяти и DB-Контролы + редактирование хранимкой. Хранимка вернуда ДА - Post, НЕТ-Cancel. И никакого переоткрытия датасета.

ХП может изменить значения нескольких полей, как тогда быть?
Не смотрите на пример, это частный случай

Фэйтл ЭраЛеонов Юрий...ХП может изменить значения нескольких полей, как тогда быть?
...
Перечитывай ОДНУ запись. Ту, которая изменялось. Одну - единственную.

КАКИМ ОБРАЗОМ??? В другом датасете одну запись открывать и потом подкидывать? Не понимаю...

DimaBrЛеонов ЮрийХП может изменить значения нескольких полей, как тогда быть?
Тогда, по вашей же логике, что с одними данными работают несколько человек, вы никогда не сможете встать в то же место. Потому что того места попросту может уже не существовать.
Ваша цель спозиционироваться на редактируемой записи после переоткрытия запроса и не важно в каком виде будет грид.

Как раз важно. Цель такая: если изменение касалось не структуры данных, то позиционироваться нужно на то же самое место. Если набор изменился, тогда на эту же запись, пусть она стоит где угодно. А если в новом наборе нет этой записи, тогда идем на первую. По-моему, логично.

Фэйтл ЭраЛеонов ЮрийКАКИМ ОБРАЗОМ??? В другом датасете одну запись открывать и потом подкидывать? Не понимаю...
ХЗ, твои проблемы. Ты уперся в свой грид, про сервер и датасет не гу-гу.

Сервер - Oracle 11.2.0.4.0
TOraQuery из палитры компонент ODAC
Сам запрос перебирается динамически, все бинд-переменные заменяются значениями (была необходимость)

Фэйтл Эра https://www.devart.com/odac/docs/devart.odac.toraquery.htm

В TOraQuery есть свойство RefreshSQL: https://www.devart.com/odac/docs/devart.dac.tcustomdadataset.sqlrefresh.htm

И метод RefreshRecord есть: https://www.devart.com/odac/docs/devart.dac.tcustomdadataset.refreshrecord().htm
Который может вызываться даже автоматически: https://www.devart.com/odac/docs/devart.dac.tcustomdadataset.refreshoptions.htm
Это работает когда меняется гарантированно одна строка в наборе
А если за время, прошедшее с выборки уже были изменения по другим записям, тогда что? Они же не обновятся автоматом по изменению в БД? Или я неправ?

Фэйтл ЭраКонечно, не изменятся. Именно так и работают с датасетами в гридах: перечитывают только ту запись, с которой идет работа. Именно для этого сделаны специальный члены класса датасета - RefeshRecord и RefreshSQL.
То есть если другой пользователь изменит данные я не узнаю об этом при перечитке только одной записи.
Это помогает в однопользовательской системе, мне такое не подходит

JaDiJaDi,

опечатка, вот так в конце:



Уже пробовал такое, при установке TopRecordIndex в датасете позиционирование идет на последнюю видимую в гриде запись, а это не то что нужно.

white_niggerУже много лет как сервермоде сделан в гриде, который умеет гораздо больше чем гридмоде... И способен обрабатывать многопользовательские коллизии

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