FWD » Core Development » Database

I encountered the following issue.

There is a (database) table named order. The conversion correctly identifies the possible issue and generates the SQL name order_. The ABL source is:

FOR EACH order:
    DELETE order.
END.

The converted code looks like this:

    forEach(TransactionType.FULL, "loopLabel2", new Block((Init) () -> 
    {
       query2.initialize(order, ((String) null), null, "order.ordernum asc");
    }, 

The problems start when attempting to convert the following FQL:

    select
        order.recid
    from
        Order__Impl__ as order
    order by
        order.ordernum asc

As you notice, there are two consecutive order tokens! Somehow, the parser stops at as so only the following tree is generated:

    select statement [SELECT_STMT]:null @0:0
       select [SELECT]:null @1:1
          order [ALIAS]:null @1:8
             recid [PROPERTY]:null @0:0
       from [FROM]:null @1:20
          Order__Impl__ [DMO]:null @1:25

There is no parsing warning, this way it managed to fly under the radar and there are no issues reported to log.

I think it is difficult to predict these kind of (more or less correct) FQL statements. This is just an example, but think what the statement would look if the table's Java name was select, limit, delete, etc. A way to handle this is using table hints, but this implies we know the issue a-priori. A better solution would be FWD to handle it automatically. I wonder whether if we could avoid such issues by detecting this kind of collisions at conversion time and use an alternative Java name for these buffer variables?

This issue should be fixed in r11866/4397a (11/26/20).