java.sql.ResultSet interface

A positioned update or delete issued against a cursor being accessed through a ResultSet object modifies or deletes the current row of the ResultSet object.

Some intermediate protocols might pre-fetch rows. This causes positioned updates and deletes to operate against the row the underlying cursor is on, and not the current row of the ResultSet.

JDBC does not define the sort of rounding to use for ResultSet.getBigDecimal. Derby uses java.math.BigDecimal.ROUND_HALF_DOWN.

Table 1. Implementation Notes on *ResultSet* Methods
Returns	Signature	Implementation Notes
void	deleteRow()	After the row is deleted, the ResultSet object will be positioned before the next row. Before issuing any methods other than close on the ResultSet object, the program will need to reposition the ResultSet object.
int	getConcurrency()	If the Statement object has CONCUR_READ_ONLY concurrency, then this method will return ResultSet.CONCUR_READ_ONLY. But if the Statement object has CONCUR_UPDATABLE concurrency, then the return value will depend on whether the underlying language ResultSet is updatable or not. If the language ResultSet is updatable, then getConcurrency() will return ResultSet.CONCUR_UPDATABLE. If the language ResultSet is not updatable, then getConcurrency() will return ResultSet.CONCUR_READ_ONLY.
boolean	rowDeleted()	For forward-only result sets this method always returns false, for scrollable result sets it returns true if the row has been deleted, via result set or positioned delete.
boolean	rowInserted()	Always returns false.
boolean	rowUpdated()	For forward-only result sets this method always returns false, for scrollable result sets it returns true if the row has been updated, via result set or positioned update.
void	updateRow()	After the row is updated, the ResultSet object will be positioned before the next row. Before issuing any methods other than close on the ResultSet object, the program will need to reposition the ResultSet object.