Grid best approach

Author: (rogerw)


Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.



  1. Hi RogerW,

    if you have entities with a relationship (UP entitiy),

    just use the frame-in-frame to let uniface do all the retrieves
    and populate dummy fields of the outermost entity in the READ trigger of the UP entities.

    For dynamic or 1:many situations (DOWN entities).

    I recommend the same frame-in-frame concept to collect the data,
    but use a complete new dummy-entity as a base for the grid
    the READ trigger of the lowest DOWN entity will create the occurences.

    If you have a standard set of data, but different components to select different fields in the grid
    you can use a "product line" approach:

    Use the DOWN entity solution as a general data provider
    where the DUMMY entity presents "all" data needed in all your different grids.

    As a base for the different grids,  COPY the data provider component and purge anything but the DUMMY entity (right now this is a 1:1).
    Create a DTD (with the name of the component) from this presentation component and implement the following:
    - Send the presentation DTD using $componentname or the precompiler constant as a data-request to the data-provider
    - build your DUMMY entity with your data .

    If you need variations of the presentation with less fields:
    - take the base presentation,
    - delete the fields you do not want
    - create a new DTD
    and here we go.

    Success, Uli

    Author: ulrich-merkel (
  2. Hi Uli,

    Thanks for a good answer, although the question unfortunately was sent without too much testing from me (friday! :)  ).

    I think the main concern was that you can't use more than one entity in the grid. There has obviously been a misunderstanding here that you can't paint an up-entity in the grid-entity, which you apparently can, but you can't directly show the field of the up-entity (inner-entity)?!  But I understand the misunderstanding, what's the technical reason not being able to show fields of up-entities directly in the grid? Perhaps that's just a way to avoid the following problem with down-entities.

    I suppose that with the down-entity you mean that the whole frame-in-frame, to collect data, is completely outside the grid? 

       Regards RogerW.


    Author: rogerw (
  3. Hi RogerW,

    the "down"-entity is a many-entity (as seen from the current entity)
    the "up" is the ONE or reference entity (denoted by foreign-key fields in your entity.

    While there is always maximal one UP-occurence you can transfer teh values to the current occurence.
    A down entity implicits multiple occurences for each occurence of your current entity.

    In the latter case, a dummy entity as the base for the GRID is recommended
    where you can paint all these extra occurences you got from the many entities.

    SUccess, Uli

    Author: ulrich-merkel (
  4. Hi Uli,

    yes I know what you mean by Down- and Up-entity. Sometimes having the Down-entity situation you still can go for the Up-entity solution as the logic (fex. in read-trigger) will reduce the Down-entity to one record, ie. you get a 1:1 situation.

    However it would be interesting to know why it isn't possible to show a field of an up-entity in the grid, but you have to copy to a dummy-field of the outermost entity?

     Regards RogerW.

    Author: rogerw (
  5. Hi,

    I think someone from "the Lab" can explain it better,
    but AFAIK the implementation of the GRID is based on a single entity and the fields defined there.

    So all data to be displayed have to be defined as fields within this entity.

    Success, Uli

    Author: ulrich-merkel (