Skip to content

Examples of Reverse Engineering Issues

This page includes some common problems found when carrying out reverse engineering and a number of proposed solution to the various problems listed.

Invalid data type

Datatypes of attributes are derived from the corresponding column comments. To correct the issue describe the view to see what the datatype (including length, precision and scale) should be. For BLOB columns use BINARY and for CLOB columns use LONG_TEXT.

My attribute has length zero and the view column is also of length zero

Sometimes the column in the view has zero length. This happens when the column is defined as "select... NULL ColumnName..." and the attribute is used as a parameter to be passed to the server from the client. In this case check the Unpack_Check_Insert___ and Unpack_Check_Update___ methods to see if there's a local variable defined for the attribute - if so set the length accordingly. If you can't deduce the length from the Unpack methods you will need to check the client code.

BLOB columns should be modeled as BINARY attributes. CLOB columns should be modeled as LONG_TEXT attributes. These are also the values that we should give in column comments for the LU.

I get a warning about the length of the name of an attribute

This warning "name is longer than 26 characters when converted to DB casing" is there to notify you that the attribute can't have a corresponding Get method. This means that the attribute has to be private to the LU. If the attribute is private you can ignore the warning but note that you can't change this into a public attribute in the future. If the attribute is public there is a mismatch between the attribute name and the 'get method' name. This is bad practice but won't cause the application to fail. Please redesign whenever the opportunity presents itself.

I have a key or parent key column set as Update Allowed

Verify that the key can indeed be updated (check Unpack_Check_Update___ in the corresponding entity). If the key can be updated the property (and column comment) is correct, otherwise correct the view comment.

Unknown reference delete behavior

This error is usually given when the delete behavior is incorrect (valid values are NOCHECK, CASCADE, CUSTOM and CUSTOMLIST). The issue is often misspelled flags or the use of backslash () instead of  forward slash (/) in front of the delete behavior flag. Correct the column comment to fix the issue, but verify the desired behavior with your Product Architect since changing the flag will effectively change the logic of the application.

Unknown attribute formatting options

Alpha and Text attributes can be set to UPPERCASE, LOWERCASE, INVISIBLE and UNFORMATTED. Number and Integer attributes can be set to DECIMAL, CURRENCY, PERCENTAGE, INVISIBLE and UNFORMATTED. Date, Time and Timestamp attributes can be set to INVISIBLE and UNFORMATTED. All other formatting options are invalid and should be removed from the column comment.

I have a reference to a view that's not the main view of an entity

You will get warnings for references to views that aren't the main view of the referenced entity. This is basically because of a limitation in our column comments. References to views other than the main view must sometimes be handled manually when it comes to referential integrity (if the referenced view and the main view return different result sets). What this means is that the PL/SQL code must call the correct package for Exist controls - the generated code will not use the correct package name. There is  no need to modify the existing api/apy files since the required changes have already been done there.

How do I handle "invalid" enumeration values

Enumeration values must start with an uppercase letter and shouldn't contain any illegal characters. When you get these warnings there should be separate db and client values specified in the model in which case the enumeration value is only used in java. You should set any enumeration values to a valid (and meaningful) value. The api/apy files should not be changed. The entry should look something like this:

value NoParameter {  
   DbValue "NONE";  
   ClientValue "1 - No Parameter";  
}

Note that if the DbValue and ClientValue aren't already set you should add them manually (using the same value for both entries) before changing the actual value identifier.

I have a utility that's being reverse engineered as if it was an entity

IFS Developer Studio will sometimes incorrectly identity utility LU's as entities. When this happen, delete the entity file and continue. There should not be entity files for utilities.

I get warnings saying that the referenced enumeration isn't an enumeration

Some packages are both entities and enumerations in that they contain both the enumeration interface (encode/decode/enumerate) and the "standard" LU interface (new/modify/remove). The tool should recognize these types of packages and accept their duplicity. For the time being - if the referenced package contains encode/decode/enumerate methods then the use of enumeration instead of references is correct and the warning can be ignored.

I get a warning saying that my referenced entity is not an entity

This issue could be the result of references to views other than the main view. It could also be a reference to an enumeration type where there is a missing call to Decode in the view definition. For references to extra views you can ignore the warning, but for references to enumeration types you should contact the Product Architect to see if the Decode call should be added to the view or if translations are avoided intentionally. The error for enumeration types will also show up if the column alias does not appear on the same line as the Decode call in the view definition.

Unknown reference attribute

You will get the unknown reference attribute error if one of the attributes that make up the reference doesn't exist in the entity main view. Correct the view comment to use the correct column for the reference.

Why do I get a name conflict between attributes and associations

Associations must have a unique name in the new model. The somewhat naive naming algorithm simply takes the last of the attributes in the reference and add Ref to the name to form the name of the association. If there is already an attribute with this name (XxxRef) then there will be a conflict. To resolve this simply rename the association in the.entity file.