Strange behavior when changing entity definition and not compiling all components

Author: (BenjaminSchmidt)

Hi everybody, I got a strange behavior when changing the definition of an entity, which is painted in some components and I forget to compile all of these components. Uniface-Version: 9.30201 P222 Here´s a reduced example of the problem: I got an Entity PERSON with the fields ID and NAME. The Entity is painted on the two components S_PERSON (service) and F_PERSON (form). Now I add a new field AGE to the Entity definition (in database an also in the corresponding Uniface model). After changing and analyzing the model I compile the service S_PERSON but not the form F_PERSON. Here comes the strange behavior: When accessing data in the compiled service S_PERSON the new field AGE is not considered! It seems that I need to compile the form F_PERSON, because after compiling the service does know the new field AGE. Has anybody else the same behavior? I had this problem with different entities and components, so its not a individual case. It seems like Unfiace stores the information how to access a entity overall components, where the entity is painted. greets Benjamin


  1. The entity definition used in the application is based on the FIRST component run in the application taken from its compiled information. So in the case above, I would guess you run the form in order to call the service, and as such the entity definition is taken from the compiled form. If you triggered the service first (from the start up shell or similar) the entity definition would be taken from the compiled service. It is, however, generally safer to compile ALL components which use the entity where the entity structure has changed. I have a small component based on the dict model, which compiles all the components which reference an entity, and have downloaded one from the previous incarnation of this website, which checks in a little more detail for changes and compiles all un-compiled programs.

    Author: Iain Sharp (
  2. Many people have made utilities to compile all Uniface components that have a specific entity painted. You can try the tool Karl and I made, it is on: and on:

    Author: Theo Neeskens (
  3. Thank you both for your answers. I wonder why Uniface works this way. All information about an an entity is stored in the meta-model. So I assumed Uniface would take the access-information from there (by analyzing a model there are some compilation-files created, or not?!) When I get it right Uniface uses the information from a meta-model only for compiling a component and then binds this information to the component. In a nutshell: changing model definitions => compile all components which have the entity painted greets Benjamin

    Author: BenjaminSchmidt (
  4. Hi Benjamin, ..... but the uniface.exe only works with the compiled artifacts (you only roll out to production the *.aps, *.frm, *.svc, *.dol, *.urr etc., but no repository, no datamodel) So there has to be information about the painted entities in each of the components compilates. Whenever uniface encounteres a new entity which need to be opened, it takes the information from the active component. Thats one of the nice flexibilities: I can give you a compiled form which uses "my datamodel" whthout the need to deliver all the overhead as well.

    Author: ulrich-merkel (
  5. Hi Ulrich, but what about *.edc and *.edx. By analyzing a model there are files create like @.edx/edc. I don´t see the flexibility. For me it seems more logical to "compile" only the meta model after changing definitions at database-level and not ALL components using the meta-model definition. Wouldn´t it be easier to have the information centralized in the meta-model and not distributed components? I think changes at database-level need to be transfered to all components (so I am sure everything will work properly after my changes) - so it would be nice to have all done by "compiling" the meta model. greets

    Author: BenjaminSchmidt (
  6. Hi Benjamin, I tried to explain how uniface is working right now. Perhaps you would like to discuss your expectations with your local Compuware contact, because I am not affiliated with CPWR at all. But an enhancement of the IDF would help all of us like: Recompile all components which have this current entity (or all subtypes of the current supertype) painted There are a lot of implementations for this use-case already "on the market", but an IDF integrated implementation from "the Lab" would be accessable for all uniface customers.

    Author: ulrich-merkel (