Actually that is dangerous too. Test is the critical aspect.
Why dangerous?
Db.Validate flushes the changes to the dB and everything in its cache. That can have a timing side effect.
DBContext 201…
The DB Context is a whole novel of its own but to simplify it, it has all the db connection goo, a collection of caches for each table in the database (e.g the data model), methods to query and update the db, transaction handling, the data triggers, etc etc.
The important part in all that for this context (pun intended) is that collection of table caches. Look at one of the queries above. When they execute, the Db.ShipHead has a cache of a row in memory - along with any other previously updated data before the BPM intercepted the server logic in all the tables in memory.
If you do a Db.Validate() - ALL tables are flushed to disk, not just that row you just updated in your bpm. This can cause interesting side effects if there were further processing further down the server call that assumed a record was in memory.
The safer thing to do is only play with your data -> Do a Db.Validate(the_Row_I_Changed).
The trade off is when you are doing something in a loop like above you can pummel the db with many writes. In some cases it is safer to do nothing with the Db.Context. At the end of the server call, pending saves are flushed to the db for you so that may be faster as opposed to doing an explicit flush to disk row by row.
Which way to go? Test. Measure. Know your data that you updated.