Ignore : If the difference does not cause a change of behavior of the generated program, it may be ignored.
When you use the Beyond Compare tool, Ignore the difference means to copy the file on the right to the left.
Apply WA : In some cases, the difference may disappear by changing the programming. These cases are reported in SACs and they will be corrected in future upgrades. Meanwhile, you can apply a work-around to avoid the change of behavior of the generated program.
After this, you will have to apply the methodology again to regenerate the files and compare them again.
Apply Upgrade : In some cases, the difference disappears by applying a further GeneXus upgrade.
Verify : Some differences require a deeper analysis. You will find more information in the comment about the action that must be reviewed to solve the difference.
The following table describes the possible differences found when using Navigation Comparer tool
| Difference |
Caused By |
Action |
Comments |
| spc0027 with an attribute that should be considered as control |
See SAC 20006 |
|
|
| spc0037 with an inferred subtype attribute used in the Parm rule |
See SAC 18904 |
Ignore |
|
| spc0039: Ambiguous reference to attribute ?%1?. Subtype group ''%2'' chosen this time |
|
Verify |
See action A |
|
spc0039 and besides, in 7.5 navigation, for Non-TRN objects, the following message appeared: Warning: ATT is not instantiated
|
Change in tables navigation to infer inferred subtype |
Verify |
See action B |
| spc0043: ATT is not instantiated in 8.0 nested navigation |
See SAC 16708 |
Apply WA (reprogramming) |
|
| spc0043 and besides the attribute is an inferred formula |
See SAC 16235 |
Apply WA (reprogramming) |
|
| spc0043 in GX 7.5 and in navigation GX 8.0 solves this attribute |
|
Ignore |
|
| spc0051: Supertype %1 cannot be instantiated. Use subtype %2 instead %3 |
The use of subtype or supertype in the same object or wrongly defined groups |
Verify |
See action A |
| spc0051 and besides there are tables unnecessarily read in GX 7.5 |
|
Ignore |
|
| spc0079 and spc0080 on specifying the subtypes group |
See SAC 16389 |
Reprogramming |
|
| spc0116 with attributes by which a for each is sorted, which belong to the extended table and update base table attributes |
See SAC 19795 |
|
|
| Nested For Each base table changes |
There is a common attribute in the extended table of both For Each?s. It is related with the changes in the nested For Each?s navigations
See SAC 14557 |
Reprogramming |
Add the Defined By clause in the nested For Each |
| The tables navigation (the chosen path) to infer a secondary attribute changes |
There is more than a primary subtype in the extended table or a subtype and, in addition, the primary supertype |
Verify |
See action A |
| Table is unnecessarily read in GX 7.5 navigation |
In non-TRN objects, some For Each READs change (for subtypes), which were in the navigation but did not infer anything. |
Verify |
See action C |
| The base table of the grid (or of the implicit For Each) changes |
Grid conditions are not considered to determine the base table. See SAC 16273
|
Apply GeneXus 8.0 Upgrade 5 or higher one |
|
| GX 7.5 navigation shows For Each condition both in Loop While and in Constraint. It sometimes appears in GX 80 |
See SAC 16533 |
Ignore |
|
| Breaks in GX 80 do not show information of the join and/or constraint that was showed before |
See SAC 15768 |
Ignore |
|
| Attribute (not subtype) is inferred by subtype and not by primary supertype |
See SAC 16763 |
Apply WA (reprogramming) |
|
| Parameters do not appear in the call to redundancy programs GeneXus 8.0 |
See SAC 18466 |
Ignore |
|
| A Referential Integrity control is added in Delete although there is an if delete error() rule in GeneXus 8.0 |
See SAC 18897 |
Ignore |
|
| Constraints appear in 8.0 as object general Conditions |
See SAC 19841 |
Ignore |
|
| 7.5 navigation shows a non-instantiated attribute warning, but the navigation is solved in GeneXus 8.0 |
GeneXus 8.0 has more knowledge, and can solve more inferences |
Ignore/Review detailed navigation |
In GX 8.0 detailed navigation you can see that the attribute that previously said non-instantiated is obtained in an INTO. |
| Attributes in automatic prompts constraints change |
|
Ignore |
|
| Adds constraint in nested for each that is present in the primary for each in GX 8.0 |
|
Ignore |
|
| Formula navigation had GIVEN in GX 7.5 |
Corrected in 8.0 - See SAC 10842 |
Ignore |
|
| Formulas navigation changes |
In 7.5 version, the formula complete navigation was shown. Now, only the tree tables are shown |
Ignore |
It may be because of the change of aggregate sums. |
| The table associated with the when duplicate clause of the new does not coincide with the table of the New |
See SAC 20018 |
Apply WA (reprogramming) |
|
In case of differences that must be verified, we recommend accessing the detailed navigation of the GeneXus objects and compare the corresponding ones to be able to analyze the case.
In this type of navigation there is normally more information (mainly the INTO concept where you can clearly see what attributes are obtained in each reading), which may be useful to determine the expected behavior.
Below you will find the detailed steps to be followed for some of the points mentioned above.
This occurs when making reference to an attribute (not subtype) that may be inferred in several ways. That is to say, there is more than one primary subtype in the extended table or there is a subtype and besides the primary supertype. The specificator chooses one of the possible "paths", but it may change between specifications as from GeneXus 8.0.
How to detect it?
The difference may appear in any type of object and it becomes evident with a change in the "path" to reach the table that solves this inferred attribute. That is to say, reading more intermediate tables or simple changing the primary attribute by which the "destination" table is read (changing a subtype for another subtype or for the supertype). If the attribute to be inferred is a secondary attribute (it is only in one table), you can see that, in both cases, the navigation reaches the same destination table, although through different paths. If what you infer is the PK of a table, the destination table could be different.
Most of the time, these cases are accompanied by the following warning in the navigation list:
- spc0039: Ambiguous reference to attribute "%1". Subtype group ''%2'' chosen this time.
In some cases, the navigation may not be affected, although the spc0039 message appears anyway. This would be the expected behavior, since the navigation is maintained in the new version, but there is a warning regarding an ambiguous definition that must be corrected to avoid a change in the future.
Other cases have been found where in 7.5 it navigated more than once on the supertype table and in 8.0 it navigates just once, and by the corresponding subtype. In this case, the spc0039 message does not appear, since now it navigates by the corresponding subtype.
Another difference in the navigations related to this change is when 8.0 navigation is truncated regarding the previous version. That is to say, it does no longer read the necessary tables to infer this attribute. In this case, the 8.0 list may show the following warning:
- spc0051: Supertype %1 cannot be instantiated. Use subtype %2 instead %3
What are the reasons for this change?
- Wrongly defined groups
- Subtype has not been added to the group yet to be used instead of the secondary attribute
- Use of subtype and supertype in the same Transaction/Extended Table
- References to subtypes and supertypes in the same For Each (explicit or implicit ? base table -)
- Unnecessary readings that were done in previous versions.
How to correct them?
A. In this point, we must stop to review all the Warnings of subtypes groups appearing in the navigation list and delete the subtypes of the group *none, defining the corresponding groups.
The new controls included in the definition of the existing groups are to guarantee that the groups are defined properly. Three different situations are found:
Groups with "secondary" attributes
When there are groups that contain attributes that cannot be determined by the primary attributes of the same group, the following message is displayed: spc0040: 'Subtype group ''%1'' contains secondary attributes (%2). Secondary attributes ignored.'
Groups without primary attributes
When there are groups that do not include primary attributes, the following message is displayed: spc0041: 'Subtype group ''%1'' does not have primary attributes. Subtype group definition ignored.'
Groups with attributes that do not identify a table
When there are groups that include attributes that do not determine a base table, the following message is displayed: spc0042 'Subtype group ''%1'' (%2) does not identify a base table. Subtype group definition ignored.'
B. The problem occurs when a base table that is being considered (in the TRN or For Each group) includes, in its own table or in the extended table, two subtypes of the same supertype, and there is a reference to a secondary attribute of the table defined by this supertype.
Example:
|
TRN COUNTRY
|
TRN COMPANY
|
TRN CONTACT
|
|
CountryId*
CountryName
|
CompanyId*
CompanyCountryId
|
CompanyId*
ContactId*
ContactCountryId
CountryName
|
|
SUBTYPES GROUPS
|
|
CompanyCountryId subtype of G1.CountryId
ContactCountryId subtype of G2.CountryId
|
In this case, the following message is displayed on specifying TRN CONTACT:
spc0039: Ambiguous reference to attribute(s) CountryName . Subtype group G1 instead of G2 chosen this time.
The spc0039 message shows the alternatives available to infer this attribute and it will select one of them. This way may coincide with the previous version (in this case the navigation will be the same) or it may have changed. In any case, we recommend substituting this secondary attribute that you want to infer for a subtype, and adding this one in the corresponding group. In the previous example, substitute CountryName for ContactCountryName in CONTACT.
C. This is a specific case of the previous one, where instead of having two subtypes of the same attribute in the extended table of the corresponding base table, you have a subtype and besides the corresponding supertype. Although this was not supported in previous versions, some cases work anyway, and they may have changed.
If in this case you want to infer the attribute by the subtype, as in Case B), you have just to substitute the attribute for a subtype and add it to the group defined by the primary subtype.
The problem arises if you want to infer the attribute by the supertype and the specificator assumes the subtype path. Although in this case preference should be given to the supertype path (that usually coincides with the navigation of the previous version), there is an error in 8.0 consisting on the fact that, in some cases, it goes by the subtype. In this case, since there isn?t any group where to add the secondary and force the supertype path, the alternative solution is defining a subtype of the attribute in question in the group currently chosen by the specificator. In this way, the ambiguity is also solved. This will be corrected in future versions by giving preference to the supertype when detecting this type of ambiguity (SAC 16763).
D. Previously, the use of the subtype and supertype in the same object was correctly solved for the primary. Now, the following message appears:
- SPC0051: Supertype %1 cannot be instantiated. Use subtype %2 instead %3 (SAC 13990).
In 7.0, the following error was displayed for the secondary: "Att cannot be inferred". Currently in 8.0, the message displayed is also the spc0051, which provides more information.
E. Some cases were detected where the same table is read twice to infer the same attributes. This problem occurs when you have subtype and supertype in the same Transaction/Extended Table (this is a specific case of the C case). One of the readings was made by the supertype of the TRN and the other by the subtype of the previous one, which is inferred by another FK.
This is the case of subtype of subtypes; in previous versions it was not possible to infer secondary subtypes. If this feature was anyway used in versions previous to GeneXus 8.0, now, the READ corresponding to the supertype table appears to solve this inference. In 7.5 navigation for NON-TRN objects, the following message was displayed: Warning: ATT is not instantiated.
If the secondary supertype was previously used (which was an alternative solution in these cases), now, the corresponding READ is added, but the spc0039 warning also appears.
When the only navigation difference is that there are fewer read in GeneXus 8.0, you must Verify that there is no warning in the section. -- Warnings / End Warnings -- of this text file corresponding to GeneXus 8.0 navigation that indicates that some attribute cannot be instantiated.
If this is the case, this navigation difference can be ignored.