Bizarre Temp-table Name Resolution

[GregTomkins]

I'm not looking for a solution, I just thought some of the Progress old-timers like me might appreciate this.

Connect to sports2000 (it doesn't happen with sports or isports for semi-obvious reasons) and run this code. Yeah, I know it's not proper code, that's not important. And sorry about the capitalization

DEF BUFFER mybuf FOR TEMP-TABLE t.
DEF VAR loop AS I.
BUFFER mybuf:FIND-FIRST().
DO loop = 1 TO BUFFER mybuf:NUM-FIELDS:
    DISP BUFFER mybuf:BUFFER-FIELD(loop):NAME BUFFER mybuf:BUFFER-FIELD(loop):BUFFER-VALUE.
END.

Verified with 10.2B05 only. Maybe it's OK in older or newer versions.

That's hardly a serious problem, but, it's probably the strangest flat-out has-to-be-a-bug I've seen, no?

 

[Rob Fitzpatrick]

Yeah, it's weird. In my opinion it shouldn't compile. It makes a little more sense if you add a down frame:

def buffer mybuf for temp-table t.
def var loop as i.

buffer mybuf:find-first().

do loop = 1 to buffer mybuf:num-fields with frame a down:
    disp buffer mybuf:buffer-field(loop):name
         buffer mybuf:buffer-field(loop):buffer-value.
end.

Output:

EmpNum   1   
DayRecor 01/05/98
TypeReco part
AMTimeIn  855
AMTimeOu     
PMTimeIn     
PMTimeOu  115
RegularH 4   
Overtime .25

Now try:

find first timesheet.
disp timesheet with 1 col.

Output:

        Emp No:          1
  Day Recorded: 01/05/1998
Type Recorded: part  
    AM Time In:  8:55 
   AM Time Out:       
    PM Time In:       
   PM Time Out:  1:15 
Regular Hours: 4.    
Overtime Hours: 0.25

This was with 11.3.2. It's the same in 11.6.

 

[GregTomkins]

Hmm, seems like almost nobody shares my fascination for this weird corner of Progressdom. Anyway, it turns out that this same issue affects everything, eg:

find first t.
disp t.

... or ...

def temp-table whatever like t.

These work, too, even if the DB doesn't have a table named 't' in it (and these are the only lines of code being compiled).

But the DB has to have *some* table that *starts with* 't'. Yet, apparently, this is not true for ANY other letter. 't' is special!! How weird is that!

 

[Rob Fitzpatrick]

Yet, apparently, this is not true for ANY other letter. 't' is special!! How weird is that!

I don't think "t" is special. It just works because it's an unambiguous abbreviation of "timesheet" in sports2000. Other unambiguous abbreviations (e.g. c, d, e, v, w) of application tables also work, as do longer abbreviations like ti, tim, etc.

 

[TheMadDBA]

"t" isn't special like Rob says... it is the abbreviation being unambiguous that causes that behavior.

Abbreviations are one of my Progress pet peeves... along with unqualified column names for tables and temp-tables. Neither of them make sense and should have never been supported imo.

 

[Rob Fitzpatrick]

I seems like a lot of compiler features were added in the name of developers typing less.

 

[GregTomkins]

On my system (10.2B05) and with a more realistic DB (eg. not Sports), 't' seems to be special... we have dozens of tables that start with 't' and dozens that start with 'a' ... 't' has this behaviour, other letters including 'a' do not.

--

100% agreed about abbreviations and unqualified field names, although, some of their keywords are so verbose (DEFINE VARIABLE I'm looking at you) that some shorter form should obviously be available, but ideally as the ONLY form.

 

[TheMadDBA]

Hmmm. I can't seem to reproduce that on 10.2b08.

Is it picking the first table that starts with t?

 

[GregTomkins]

OK, after looking a bit more closely, I have to more-or-less concede this one.

It's actually picking the *last* one (that starts with 't'), which happens to be the _only_ table we have that starts with a unique combination of the first two letters. Eg. all our 'a' tables start with 'ac', etc. It still doesn't make sense that 't' is unique, it's not, but there is some sort of pattern there.

 

[Rob Fitzpatrick]

I can't repro in 10.2B08 or in 10.1C. When the DB contains two tables called test1 and test2 I get a 725 error with "find first t". It compiles once I delete one of the tables.

Now I'm curious. Greg, I wonder if there is something particular about the schema of your application DB that is causing this behaviour. Can you start with an empty DB and add two tables starting with 'a' and two starting with 't' and reproduce this?

 

[Rob Fitzpatrick]

It's actually picking the *last* one (that starts with 't'), which happens to be the _only_ table we have that starts with a unique combination of the first two letters.

I tried "find first t" with "test2" and "tst"; got a 725. I tried "find first s" with "salesrep" and "state" (also starting with unique two-letter sequences), also got a 725.

I'm not saying you aren't seeing a bug. But if you are, I can't yet see what it is.

 

[GregTomkins]

I'm not sure if you are referring to an otherwise empty DB, or a variation of Sports. But, try adding a third table called 'test1'. If your system is consistent, 't' will resolve to 'tst'.

 

[Rob Fitzpatrick]

I'm not sure if you are referring to an otherwise empty DB, or a variation of Sports. But, try adding a third table called 'test1'. If your system is consistent, 't' will resolve to 'tst'.

In 10.2B08, with tables test1, test2, and tst, "first first t" fails with a 725. This was in a copy of sports, but I also did it yesterday in a copy of empty.

 

[TheMadDBA]

I also cannot reproduce this.. even tried making some of tables hidden to see if that was part of the issue.