Spotting database changes in *FRM entities.

Author: (Iain Sharp)

We have a user interface requirement/desire to prompt the user for "save changes" on clear and quit, but (to avoid the "cry wolf" issue) obviously only when there have been changes made.  We also have non-database fields declared in the model for calculated values etc.  It used to be that we could differentiate between modifications which would carry to the database and those which wouldn't by using the $occdbmod. If, however, we switch to using the FRM component subtypes from the model on our forms, this functionality (silently) fails, as nothing is in the database (because the entity isn't a database entity any more).  $occmod does not differentiate between db fields and non db fields and therefore is giving many false positives.  Am I missing a trick here? Is there some way to know whether the database fields within a FRM component subtype have changed?    (Uli - I realise I could probably 'roll my own' by looping through all the fields for the entity and using $properties to determine if it's a database field and then checking something else ($fieldmod?) but frankly it'd be easier to sanity check all the assignments to the non database fields to ensure that they are always done /init, and that is the work I am trying to avoid...) 


  1. 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  

    putlistitems/occ/modonly List, Entity delitem/id List, "nonDBfield1" delitem/id List, "nonDBfield1" ... if (List != "") messsage "modified"
    BTW: I would recommend the dITo Uniface Reflection (DUR) for an efficient processing
    with automatic update when fields change, but these modifications are pretty rare.

    Author: ulrich-merkel (
  2. 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

    Author: Knut (
  3. ... and the functional subtypes SSV, SVC and ESV are still database ones.

    Author: ulrich-merkel (
  4. 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.)

    Author: Iain Sharp (