Like I said, if changing the first column will cause it to be in violation of a constraint until the second (third, fourth, etc) columns are also changed, you can't commit the update until all columns are changed.

ie: Loan amount has to be lower that purchase amount. If you want to raise both values you have to raise the purchase amount first. This case can be handled easily by simply warning the user and making them change the other field first. But what about a case where you actually need to update two fields in the same transaction to maintain referential integrity?

This is only a problem in a situation with multi-column constraints, but I would avoid it anyway. Business rules can change, and constraints can be added to tables after the UI is built.