Something like this, maybe?

# Transform hash into two arrays
my @fields = keys %{$record_ref};
my @values = map { $record_ref->{$_} } @fields;

my $sql
    = "UPDATE $table SET "
    . join( '=?,', @fields )
    . "=? WHERE $clauza_where";

# print "sql=",$sql,"\n";

eval {
    $sth = $dbh->prepare($sql);
    $sth->execute(@values);
    $dbh->commit;      # commit the changes if we get this far
};

if ($@) {
    warn "Transaction aborted because $@";
    $dbh->rollback;     # undo the incomplete changes
}
[download]

Update: fixed small typo regarding unmatched right curly bracket

UPDATE "table_name"
SET column_1 = [value1], column_2 = [value2]
WHERE {condition}
[download]

This is because hashes do not have a standard internal order, the returned order of keys or values is random, unless you sort them.

Correct, but keys, values, and each use the same order for the same hash. From perlfunc:

Entries are returned in an apparently random order. The actual random order is subject to change in future versions of perl, but it is guaranteed to be in the same order as either the keys or values function would produce on the same (unmodified) hash. Since Perl 5.8.2 the ordering can be different even between different runs of Perl for security reasons [...].

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

my ($id) = delete $data_to_insert{id};

my $sql = "UPDATE some_table SET "
    . join( '=?,', keys %data_to_insert ) . '=? '
    . 'WHERE id=?';

$dbh->do( $stmt, undef, values %data_to_insert, $id );
[download]