FWD » Core Development » Database

I have the following test case:

def temp-table tt1 field a1 as dec.

DEFINE VARIABLE hBuffer AS HANDLE NO-UNDO.
CREATE BUFFER hBuffer FOR TABLE "tt1".

def var dec1 as dec.
hBuffer:BUFFER-CREATE(). 
hBuffer::a1 = 1.56.

dec1 = absolute(hBuffer::a1).
message dec1.

Which converts in:

RecordBuffer.openScope(tt1);
RecordBuffer.create(hBuffer, "tt1");
hBuffer.unwrapBuffer().bufferCreate();
hBuffer.unwrapDereferenceable().dereference("a1", decimal.fromLiteral("1.56"));
dec1.assign(abs(new integer(hBuffer.unwrapDereferenceable().dereference("a1"))));
message(dec1);

Value of the dereference field gets wrapped into a integer constructor, which cause the lost of decimal floating point. This happens because in SignatureHelper.map_func, KW_ABS function is defined with ParmType.NUM parameter.

In ExpressionConversionWorker.parameterTypeName, if the parameter is of type ParmType.NUM it gets the default value of type ParmType.INT

The change looks good. The only unknown is what happens if h::f1 is i.e. a character - is there an ERROR condition thrown?

Teodor: please check this.

The incompatible data type error is thrown (223) when the input parameter is not an NumberType, with an Error condition (execution is stopped afterwards).

def temp-table tt1 field a1 as dec.

DEFINE VARIABLE hBuffer AS HANDLE NO-UNDO.
CREATE BUFFER hBuffer FOR TABLE "tt1".

def var dec1 as dec.
hBuffer:BUFFER-CREATE(). 
hBuffer::a1 = 1.56.

dec1 = absolute(hBuffer::a1).
message dec1.

def temp-table tt2 field f1 as character.

DEFINE VARIABLE hBuffer2 AS HANDLE NO-UNDO.
CREATE BUFFER hBuffer2 FOR TABLE "tt2".

hBuffer2:BUFFER-CREATE(). 
hBuffer2::f1 = "Hello".

DO ON ERROR UNDO, LEAVE:
    dec1 = absolute(hBuffer2::f1).
    message "After!". // this is not printed
END.

message "Outside block!". // this is printed

Then a character field has a valid number representation, this still does throw the same error.
On this and on the previous note, I mean for the 4GL behavior. The changes from this branch should be changed to match with this behavior, since it does not throw this error on FWD.

Committed revision 16111 on task branch 10398a:
- ABS builtin function should raise error condition when the data type is invalid.

Please check if the bdt.isUnknown(), also - I assume no ERROR condition is raised in this case, and it just returns unknown.

Committed revision 16112 on task branch 10398a:
- ABS builtin function should not raise error condition when bdt is unknown.