грид привязан к ADODataSet, после добавления/удаления записи делаю
Close и Open

как реализовать восстановление курсора на туже позицию?
фактически сохраненные BookMark работают, но после закрытия датасета они становятся невалидными, но встают на нужное мето тем не менее 

сейчас реализовано так:
при редактировании - нормально BookMark срабатывает
при добавлении - получаю ID добавленной записи и руками встаю на нее
проблемы начинаются при удалении... можно конечно запомнить ID следующей и предыдущей записи... но что то как-то некрасиво мне кажется так будет.

важно курсор установить на нужную позицию в конечном визуализаторе (TDBGrid, TdxDBTreeList, etc.), а не в датасете.

можно поподробнее... как запомнить положение курсора в гриде и как его потом восстановить

Еслия я правильно понял, ты хочешь восстановить курсор не на ту запись, которую удалил) Тогда на мой взгляд лучше Locate ничего не придумать, его ж не просто так придумали. Вот сохраняешь ID записи, потом его находишь снова

  если все же удаляешь именно эту запись, то после делете делаешь next и запоминаешь уже вновь полученный ID

Это сообщение отредактировал(а) Kbl4AH - 24.2.2009, 22:14

это шутка такая?   

Kbl4AH, весьма спорный код.
В многопользовательской работе даже добавив запись RecordCount после Close/Open может вернуть меньшее кол-во.

demoded, а чем так не нравится locate?
При добавлении/удалении DataSet перемещается на нужную запись.
После удаления вопрос, что хочет увидеть пользователь? Первую, последнюю, следующую после удаленной, предыдущую?
Спроси у заказчика что ему надо, обычно нужно следующую после удаленной.

Бесспорно... Для многопользовательской работы не подойдет...
Как, по-моему, и не подойдет Locate для такой работы... Никогда с ним не сталкивался, сейчас глянул... Как после открытия датасета искать запись, которой в результате многопользования может уже не быть?
Deniz, приведи пример с использованием Locate, а то я более-менее однозначный алгоритм не могу сочинить (а мне иногда требуется, как и demoded, четкий алгоритм  для таких же целей).

Это сообщение отредактировал(а) Kbl4AH - 25.2.2009, 09:09

locate всем устраивает и использется, но при удалении (допустим надо перейти на следующую запись) приходится руками отслеживать ситуацию если удалили последнюю запись в ДатаСете и надо перейти не на следующую а на предыдущую.
хотелось завернуть это дело раз и навсегда в какой-нибудь собственный BookMark, но что-то опыта маловато. оставил пока так:


Это сообщение отредактировал(а) demoded - 25.2.2009, 13:35

все достаточно тривиально, но на один select больше.
Сделаем некоторые допущения:
1. Алгоритм работает для удаления (для insert/update не вижу смысла)
2. После удаления, должна быть активна следующая за удаленной запись.
3. Если удаляемая запись была последней, то активной будет последняя.
4. Есть набор полей, по которым сортируется набор данных
5. Добавление к ним ID сделает набор уникальным. (для примера возмем сортировку по уникальному табельному номеру, тогда добавление ID не потребуется)
Идея:
1. Сохраняем в параметры набор полей из допущения 4
2. Удаляем запись.
3. Close Open
4. В дополнительном запросе делаем что-то типа 
5. 
Примерно такой алгоритм будет работать в многопользовательской среде, и в четверге тоже   
Можно дорабатывать.

DatasSet1.lookup(....) работает быстрее за счёт того, что курсор не бегает по набору данных

demoded, 
Если речь идет о TDBGrid, то ИМХО стоит привязываться за DataSet.RecNo
что-то типа

  
Если в качестве визуализатора использовать нечто типа "DBTreeList", то фокусировка должна завязываться за свойства трилиста.
FocusedNode... и т.д. 
Если актуально - дораспишу.

Не понял, зачем тут доп. запрос...
А если после открытия датасет в нем ни одной записи не останется - ошибка?
ЗЫ. Пост для Deniz.

Это сообщение отредактировал(а) Kbl4AH - 25.2.2009, 19:32

для этого и написана проверка

pseud, я длительное время не обновлял форум, поэтому, адресуя сообщения Deniz, не заметил сообщения Akella и твое...
Хотя и из контекста видно, что мой пост являлся ответом не на твой...
Так что не сердись  

все равно перемещаться придется.

доп. запрос нужен для определения сл. записи после удаленной.

я, конечно, могу за тебя весь код написать, со всеми проверками и т.д., но стОит ли?

все таки привязываться к номеру записи не лучший вариант.

Это сообщение отредактировал(а) Deniz - 26.2.2009, 06:42

Конечно, не нужно...

Для случая с удалением вариант pseud имхо - лучший из рассмотренных...
Хотя и вариант с Locate не стоит сбрасывать со счетов, но применение его я пока вижу только в частном случае изменения номера записи после апдейта из-за сортировки записей средствами грида, а не датасета... но доп. запрос точно не нужен... можно и без него определить следующую запись...
ЗЫ. получается, что универсального решения, все делают так, как предпочтительнее...

не помню, что там с сортировками у TDBGrid.
побыстрому пробежав по TDBGrid и TDataSet, пришел к выводу что сортировка таки средствами SQL.
Следовательно завязываться за номер записи - приемлемый вариант.