If you have ever activated a form which contains multiple occurrences of an entity, and from this you have activated a child form which attempts to retrieve from the same entity you may have noticed a conflict between the two forms. This is because UNIFACE cannot create a new hitlist for an entity while there is an incomplete stepped hitlist in existence. There are several ways to resolve this situation:-
- The default behaviour is for the current hitlist to be completed before the new one is created. If you are testing this on a small database with only a few occurrences this may not be noticeable, but on a live database with many thousands of occurrences there could be a considerable delay before the second retrieve completes and the form is displayed.
- You can truncate the hitlist at the end of the current step by issuing a
release/e command. This means that the second retrieve can take place immediately without any delay. The only disadvantage to this is that occurrences which are not in the hitlist when it is truncated are lost and cannot be viewed without issuing an additional retrieve.
- You can open up another database path for the second form by inserting TRANSACTION=TRUE in the instance properties argument of the
new_instance command. This enables the current hitlist on the first database path to remain unaffected by any activity on another database path. The only disadvantage to this solution is that it increases the number of connections to the database. This will certainly add to the memory requirements on the database server, and may cause problems if there is a maximum limit on the number of connections.
Another way of avoiding this conflict is to use a different entity in the second form. There are two possibilities:
- Create a database view. This would normally be used in the multi-occurrence form as it may require the additional selection criteria that would be available. As database views are normally read-only it does not matter if they are referenced in multi-occurrence forms as these are normally read-only as well (at least in my development methodology they are).
- Create a copy of the entity in the application model. It is important that this is a COPY and not a SUBTYPE as Uniface will treat subtypes as if they are the supertype, so no advantage will be gained. To avoid having to create a corresponding duplicate entity in the physical database you should insert an entry in the assignment file which redirects all activity on the copy entity to the original. Unlike a database view this will provide full write access on the copy entity. The only disadvantage to this solution is that any changes to the original entity must be also be made to the copy, otherwise unexpected results will occur.
Each of these solutions has its own set of advantages and disadvantages, but hopefully there is something there that would be suitable for your set of circumstances.
Tony Marston
22nd July 2001
mailto:tony@tonymarston.net
mailto:TonyMarston@hotmail.com
http://www.tonymarston.net
