FWD » Core Development » Database

The server project exposed a problem with the temp-table fields defined using the LIKE clause, when the target field has validation. In 4GL, the VALIDATE clause forces the validation at the source field to be copied at the target field (and this was not honored at all by P2J). The problem in the server project was with a field definition like this:

def temp-table tt1 field f1 like person.schedule[1].

where if person.schedule had these clauses:

  VALEXP "length(input schedule[1]) > 0" 
  VALMSG "aa" 

the parser copied them to the tt1.f1 field. Later, during P2O generation, the rules somehow got confused by the fact that the valexp reference had a subscript operand and thought that the tt1.f1 was extent too. This was a tough one to crack, until I managed to isolate the code which produces the error.

The attached update fixes only the cases of "VALIDATE clause is not specified", by removing any VALEXP and VALMSG nodes. I did not test, but I think when the VALIDATE clause is specified and there is VALEXP at the source field, then the source field name needs to be replaced with the target field name, to make the validation expression work. And, IIRC from browsing the sources for other issues, the server project does use the VALIDATE clause. So, this task should remain open for discussion until we identify if LIKE ... VALIDATE is used by the server project.

This is going through conversion regression testing now.

This fix removes the extent annotation from the source field reference in the VALEXP. What is still needed to do:

1. remove the VALEXP/VALMSG nodes if the VALIDATE clause is not present in constructs like DEF TEMP-TABLE tt1 LIKE book.
2. fix the source field references in the VALEXP to reference the new field.

With this update, I hope we can get past compile errors, but the final fix will need to solve the two issues above.

New version of the update, which solves the VALIDATE when used with DEFINE TEMP-TABLE tt1 LIKE source VALIDATE. Also, it rewrites any field references of the source node in the VALEXP, to reference the new node.

I will put this through conversion regression testing.