Description
When Refresh is called one of these actions will be taken.

Here's some more hints about refreshing data:

There are different ways that you can refresh data with IBO. You have listed one of them. However, it is the most crude and inefficient. This forces all records previously fetched to be tossed and then completely re-fetched from the server. This may be desirable in some cases though.

There are these methods and properties to consider. Most of these only apply to the IB_Query (TIB_BDataset classes).

The Refresh method keeps the whole row buffers in memory but the list of keys that define the dataset are refreshed. Thus, if a new record was added then it would become included in the dataset. Or, if deleted, its key would not be fetched again and its whole record buffer would eventually be garbage collected by not being included in the dataset again.

This method is used internally when the OrderingItemNo property is changed and works especially well because the whole record buffers stay in memory and only the keys need to be fetched back in. As they are fetched back in according to the new ordering the individual row buffers are associated back to the keys and do not need to be fetched from the server again. Thus, the dataset is sorted and refreshed by fetching in the key columns only.

There is also the RefreshAction property that determines how the refresh is to end up. It can behave as though it were being opened the first time. Or, after it is opened again it will go to the RowNum that it was on prior to the refresh. Or, it will go to the same record as it was at before based on the Bookmark.

There is also the InvalidateRows method that will keep the current list of keys and cause all of the individual record buffers to be fetched from the server again.

If you combine Refresh and InvalidateRows then the dataset will be entirely refreshed as if you set active to false and then true. You may also call the RefreshAll method to accomplish this

You can also invalidate individual rows by calling the InvalidateRowNum() and InvalidateBookmark() methods. This is great for reflecting changes that occur in separate datasets or by calling a stored procedure.

FYI. When a record goes into dssEdit state that row is automatically invalidated because it needs to fetch the record again in order to establish a cursor context. I perform updates and deletes using positioned WHERE CURRENT OF < cursor name > statements.