Каким способом лучше сохранять текущий курсор в TDBGrid после внесений изменений в таблицу процедурами INSERT INTO..., DELETE FROM...,UPDATE...SSET... и последующим выполнением ExecSQL. С помощью TBookMark это не совсем удобно

Locate по униальному ключу в наборе данных
т.к. после переоткрытия датасета букмарки от предыдущего использовать нельзя

а в случае после использования DELETE FROM... как быть?

Смещение назад(вперед), потом [2], потом [1].

PS
При использовании компонент прямого доступа вся эта смешная суета не нужна...

подскажите, плиз, какого именно компонента прямого доступа

> С помощью TBookMark это не совсем удобно


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

>Johnmen ©   (31.10.08 13:28) [3]
>При использовании компонент прямого доступа вся эта смешная суета не нужна...

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

>Сергей М. ©   (31.10.08 14:18) [5]
>Зато верно и универсально.

а) неверно
б) не универсально

>А в чем, собссно, заключается неудобство ?

В том, что после переоткрытия НД букмарки теряют валидность

> MsGuns ©   (31.10.08 15:53) [6]
> Ну да, вместо смешной суеты будут несмешные эффекты вроде того,
>  что будут видны "убитые" кем-то записи и, наоборот, не видны добавленные.

С чего ты это взял???

> MsGuns ©   (31.10.08 15:53) [6]


Тогда давай уж подробно по обоим пунктам, с аргументами ессно ..


> после переоткрытия НД букмарки теряют валидность


А никто и не ведет речь про переоткрытие.

>Сергей М. ©   (31.10.08 16:00) [8]
>Тогда давай уж подробно по обоим пунктам, с аргументами ессно ..

Будь ласка:

а) неверно

Неверно потому, что после любого обновления НД, влекущего за собою изменения в таблице, содержащаяся в нем информация не будет достоверна пока не будет перечитана с сервера

б) не универсально

Не годится для многих случаях, например при условии серверного курсора или при однонаправленных курсорах

> MsGuns ©   (01.11.08 15:47) [9]


> после любого обновления НД, влекущего за собою изменения
> в таблице, содержащаяся в нем информация не будет достоверна
> пока не будет перечитана с сервера
>


Ну, положим, не любого, а касающегося только записей, на которые перед обновлением в НД были сделаны закладки


> или при однонаправленных курсорах


Здесь да, согласен.
Но при этом о закладках вообще не может идти речь.

> MsGuns ©   (01.11.08 15:47) [9]


> после любого обновления НД, влекущего за собою изменения
> в таблице, содержащаяся в нем информация не будет достоверна
> пока не будет перечитана с сервера
>


Ну, положим, не любого, а касающегося только записей, на которые перед обновлением в НД были сделаны закладки


> или при однонаправленных курсорах


Здесь да, согласен.
Но при этом о закладках вообще не может идти речь.

>Сергей М. ©   (01.11.08 16:15) [10]
>Ну, положим, не любого, а касающегося только записей, на которые перед обновлением в НД были сделаны закладки

 Совершенно не колышит, была ли сделана закладка или нет на записи, которую но момент "локального" рефреша физически удалили из таблицы. Т.е. в сетке пользователя она отображается, но на самом деле ее уже нет в таблице. Причем здесь букмарки ?

> MsGuns ©   (01.11.08 19:18) [12]


Что ты подразумеваешь под локальным рефрешем ?

Из справки по TDataSet.Refresh:

Re-fetches data from the database to update a dataset’s view of data.

procedure Refresh;

Call Refresh to ensure that an application has the latest data from a database. For example, when an application turns off filtering for a dataset, it should immediately call Refresh to display all records in the dataset, not just those that used to meet the filter condition.

Note: The Refresh method does not work for all TDataSet descendants. In particular, TQuery components do not support the Refresh method if the query is not “live”. To refresh a static TQuery, close and reopen the dataset.

TDataSet generates a BeforeRefresh event before refreshing the records and an AfterRefresh event afterwards.

Note: Most datasets try to maintain the current record position when you call refresh. However, this is not always possible. For example, the current record may have been deleted from the server by another user. Unidirectional datasets have no mechanism for locating the current record after a refresh, and always move back to the first record.

Warning: Unidirectional datasets refresh the data by closing and reopening the cursor. This can have unintended side effects if, for example, you have code in the BeforeClose, AfterClose, BeforeOpen, or AfterOpen event handlers.

FIBPlus юзать надоть, а не приблуды всякие. FullRefresh там неимоверно рулить!