FWD » Bugs

@45130 - recreate:

CAN-FIND() has a Progress 4GL compilation quirk (shocker!) where it will resolve field name abbreviations that would be ambiguous in normal code.

Consider this code:

define temp-table tt field ambig-one as int
                     field ambig-two as int.

if can-find(first tt where tt.ambig = 14) then
do:
   /* whatever */
end.

That code will compile even though the ambig reference appears (to me and to our tools) to be an ambiguous abbreviation of the tt table's field names.  Since this table has 2 fields that begin with ambig, it was my understanding that tt.ambig would be ambiguous.  The shortest abbreviations that are unique are tt.ambig-o and tt.ambig.t.

Here are some notes from a person that wrote some test code and ran it:

"It appears that in CAN-FIND statements, Progress will resolve an ambiguous field names to the first field in the table
definition that matches.  I've tested for both DB tables and temp-tables, and both seem to work this way.  It does parse the CAN-FIND statement - if you put an invalid query in, it will error when you try to compile." 

The key here is that:

1. This is not a case of things not being parsed at compile time.
2. There is a resolution mechanism that needs to be implemented for P2J's parsing of CAN-FIND().

Imported from JPRM on 2012-04-12 11:23:06.015:

TASKID      = 6107
PROJECTID   = 124
STATUS      = 3 (Hold)
DESCRIPTION = ambiguous field name in CAN-FIND() - Progress quirk
OWNER       = GES
ASSIGNEE    = 
BILLABLE    = false
PRIORITY    = 5 (Normal)
PHASE       = 52 (Problem Resolution)
COMPONENT   = 97
ESTEFFORT   = 0.000000
ESTSTART    = 2011-12-06
ESTSTOP     = 
ACTSTOP     = 
CASENUM     = 
VENDORID    = 
COMMENT     = ''
LASTWIP     =