Here, in a nutshell, is what I think you should be doing.   Fortunately, it is an easy change:

1. You will need to use two statement-handles:   one for the SELECT statement, the second for the UPDATE.   As it is, you are destroying(!) the SELECT statement while you’re fetching from it, and that’s why the loop ends.
2. The UPDATE statement should use placeholders, not literal text, and so it should be PREPAREd once, outside of the loop, then executed repeatedly with a different set of substitutions for those placeholders each time.

For example, in relevant parts ... (extemporaneous coding, might have syntax errors ...)

# LET'S GIVE MEANINGFUL VARIABLE-NAMES TO THE TWO STATEMENT HANDLES ..
+.
$sth_select = $dbh->prepare("SELECT volumeletter,peernodes from VolDat
+a order
+ by volumeid");
$sth_select->execute();

$sth_update = $dbh->prepare("UPDATE VolData SET volstatus = ? WHERE vo
+lumeletter = ?");
# NOTICE THAT THE '?'S ARE NOT ENCLOSED IN QUOTES!
[download]

... and ...

$sth_update->execute( [$vol_current_state, $vol] );
[download]

The question-marks in the prepared statement (which are not enclosed in quotes) act as “placeholders” for values which are provided each time the prepared statement is executed.

NOTE:   In the case of an SQLite database, you should also enclose the loop in a transaction.   When an UPDATE statement is executed outside of a transaction, SQLite will physically verify (re-read ...) the data after it has written, more than doubling the I/O activity and bringing things to a crawl.   When a transaction is active, SQLite performs the expected “lazy writes.”   This is not-so important for other database engines, but it is crucial for SQLite.