Hi Joe;
Yes, this has normally noting to do with any DB Triggers (although it is possible if the Trigger is a "before Update" one). This is an internal check performed by the DWO's internal code to see if DB column data has changed between when the DWO retrieved the original DB data into its Primary Buffer and how that now compares to the current state of the DB's related potential column updates.
The DWO's DB updating mentality by default is totally "optimistic" locking approach. That is to say that it tries to select all related data you are requesting "assuming" that nothing else will change the DB's related row data between your changes and the update(s) it needs to process. Any data changes in the DB (or what the DW perceives as a change) is checked. If the original buffer values are not the same as the row being updated - the DWO then errors out on the message that you are getting.
The default DWO updating scheme that can easily lead to your dilemma, is: "Key and Updatable Columns". That means that no column in the DWO can have its data changed on the DB before the update will be processed. This is a very risky (optimistic) approach, but can be handled by catching this error in the DC/DS control and then issuing a "ReSelectRow" to refresh the current DWO's Primary/Original buffers to let the App user try the changes again. Normally, most PB developers (hopefully) would choose the update option "Key and Modfied Columns" which can greatly mitigate the DW error message. Especially if any columns are protected from being changed as this limits what the DWO checks during the Update cycle.
My first suggestion would be to check the Update Properties on your PB 9 based DWO and see if the migrated PB2017 DWO is using the same settings. If not, realign the PB2017 to the PB9's settings & retry. If this is not the case, then try changing the PB2017's DWO "Key and Updatable" update setting to "Key and Modified" and see if that helps. FWIW: I build almost all my App DWO's this way using the "Key and Modified" setting.
In extreme cases where various Triggers are firing before DB updating or the Apps DWO PowerScript logic is intervening in the UpdateStart/END events, etc - I sometimes have to use a DWO Update setting of "Key Columns" only.
HTH
Regards ... Chris