As a suggestion (needs to be tested): we start with an occlist then manually "delitem/id" the non-db fields if List is not empty at the end, we have a  dbmod  

Iain, Have you looked at $occcrc? I've used it in the past where I assign the value of $occcrc at the time when I read the record - to a non-db field. Then, at the time of Quit/Accept of the form, I check to see if $occcrc is the same. That did the trick for me... Regards, Knut

... and the functional subtypes SSV, SVC and ESV are still database ones.

Knut, no I haven't. Does it ignore non db fields? I guess it must. I'll have a look.  Uli, yes I get the other component subtypes still have this functionality, but the frm one is non database specifically for use in the UI and this prevents some issues with empty key fields and such (because they're assigned at the service level), so changing over to non-database subtype is actually the goal, but is being hampered by the amount of extra work then required to determine the response to $occdbmod or (actually more properly) $formdbmod.  I should give some history. About 15 years ago, and in conjunction with a Uniface engineer, we decided we needed the functionality of the form component subtype before it was even a gleam in the lab's eye. We did this by creating a copy of every entity in the model set up as non-database (we called them the _UI entities, for user interface). This allowed us to have UI level modelled behaviour and Business level modelled behaviour separately, and all the other good things you can now get with component subtypes. However, we were stymied by the lack of an equivalent for $formdbmod. So we changed all the modeled entities to Database, not Non-database and the behaviour was easy. We carefully don't create these entities in the database and never retrieve, lock or write them. All is so far good.  I have a plan to try and move the code from these 'entities' into the component subtype for forms, which I should be able to do with some judicious exports, mass updates and imports. In order to bring our client server slightly more back in line with Uniface's current direction.  As, however, the component subtype is non-database, my original problem of not being able to sensibly spot $formdbmod to prompt for "Save changes" returns.  I have about 3200 entities across 1500 forms to update, so something nice and generic and easily search and replaceable for $formdbmod would be preferable. (Actually, $formdbmod working for user interface components where using Uniface's current design for UI modelled entities would be preferable, but hey.)