For some types of result sets, you can use the refreshRow method to refetch data and return to the database to refetch n rows in the result set, starting from the current row, where n is the fetch size.
If the isolation level of the transaction allows, you can view the update operations of the database beyond the result set.
This method only refetches rows corresponding to existing rows in the result set but does not perform any operations 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 a TYPE_SCROLL_SENSITIVE result set for the specified query, 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, the updates of the specified row are not returned for the refreshRow method.
Format of the refreshRow method:
void refreshRow() throws SQLException
Notice
When you call this method, the operation must be in the current row, rather than beyond the row boundary or in the inserted row.
The following table lists the result set types that support the refreshRow method.
Running mode |
Scroll type |
Concurrency type |
|---|---|---|
| Oracle mode | TYPE_SCROLL_INSENSITIVE | CONCUR_UPDATABLE |
| Oracle mode | TYPE_SCROLL_SENSITIVE | CONCUR_READ_ONLY CONCUR_UPDATABLE |
| MySQL mode | TYPE_FORWARD_ONLY | CONCUR_UPDATABLE |
| MySQL mode | TYPE_SCROLL_INSENSITIVE | CONCUR_UPDATABLE |
| MySQL mode | TYPE_SCROLL_SENSITIVE | CONCUR_UPDATABLE |