For some types of result sets, you can use the refreshRow method to refetch data, including returning to the database to refetch database rows corresponding to n rows in the result set, starting with the current row, where n is the fetch size.
You can view the database update operations beyond the result set, which is however subject to the isolation level of the transaction.
Only rows corresponding to existing rows in the result set are refetched, so no operations are performed on rows that have been inserted into or deleted from the database since the original query. During a refetch, inserted rows are ignored, because these rows remain in the result set even if the corresponding rows are deleted from the database. When you attempt to refetch a row that has been deleted from the database, the corresponding row in the result set maintains its original value. Note
If you declare that a TYPE_SCROLL_SENSITIVE result set is based on a query with specific criteria, and then externally update the row so that the column values no longer match the query criteria, the driver behaves as if the row has been deleted from the database and the row is not retrieved for the query. Therefore, when you call the refreshRow method, you cannot see the updates of the specific row.
The signature of the refreshRow method is as follows:
void refreshRow() throws SQLException
When you can this method, you must be in the current row, rather than beyond the row boundary or in the inserted row.
The refreshRow method is available for the following result set categories:
Scroll-sensitive/Read-only result sets
Scroll-sensitive/Updatable result sets
Scroll-insensitive/Updatable result sets
The scroll-sensitive result set feature is implemented by implicitly calling the refreshRow method.