Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сохранение курсоров в TDBGrid [D7, IB6.x]


dmitry_12_08_73 ©   (2008-10-31 12:39:00) 

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


GRAND25   (2008-11-05 10:13:00) [1]

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


MsGuns   (2008-11-02 00:05:00) [2]

Из справки по 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.


Сергей М.   (2008-11-01 21:17:00) [3]


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


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


MsGuns   (2008-11-01 19:18:00) [4]

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

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


Сергей М.   (2008-11-01 16:15:00) [5]


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


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


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


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


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


Сергей М.   (2008-11-01 16:15:00) [6]


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


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


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


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


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


MsGuns   (2008-11-01 15:47:00) [7]

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

Будь ласка:

а) неверно

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

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

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


Johnmen   (2008-10-31 16:00:00) [8]


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

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


Сергей М.   (2008-10-31 16:00:00) [9]


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


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


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


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


MsGuns   (2008-10-31 15:53:00) [10]

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

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

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

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

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

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


Сергей М.   (2008-10-31 14:18:00) [11]


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


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


dmitry_12_08_73   (2008-10-31 13:58:00) [12]

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


Johnmen   (2008-10-31 13:28:00) [13]

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

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


dmitry_12_08_73   (2008-10-31 13:00:00) [14]

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


Правильный$Вася   (2008-10-31 12:58:00) [15]

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


Наверх

Титульная страница Поиск, карта сайта Написать письмо