Certainly, you could do this entirely on the server side ... and you might well prefer to do so.   Here, generally, is how it would work:

(1) When the user selects a set of records to process, store the complete set of records in the Session data ... which, of course, is a standard feature of any web framework, and able to store any sort of hash/array structure for you.   Save a copy as the “changed record.”

(2) As you build the HTML forms to be filled-out, include a record-ID in a hidden field.   This will identify, say, the ID of the first record that you included in the form.   Give each set of input-fields on the form a unique but arbitrary name.   Use the “changed record” as the data source.

(3) When POST data is returned, decode the names and so-forth to update the “changed record,” noting also that changes have indeed been made.

(4) When the user clicks the button that indicates he wishes to commit the changes (and, mind you, he might never) ... and, having also already processed all other POST variables ... compare the two to see what changed.   Consider presenting this information in a confirmation form.   Update the database accordingly.

Since you have retained both a “before” and an “after” version of the record, taken at the same moment in time, you can also conveniently test to see if anyone else changed the data in the meantime.   Within an SQL Transaction, query the same set of records to see if any values changed.   If not, Update and Commit.   If so, roll-back and display an error message.