Another oddity

James has some code:

PROCEDURE DetermineMaximumDemandCharge :
DEFINE INPUT PARAMETER ip-CtpApplicationMeaningType LIKE ICMAS.CtpApplicationMeaningType.CtpApplicationMeaningType NO-UNDO.
DEFINE INPUT PARAMETER ip-Factor AS DECIMAL NO-UNDO.
DEFINE OUTPUT PARAMETER op-Usage AS DECIMAL NO-UNDO.
...
END PROCEDURE.

Now, what is odd here is that CtpApplicationMeaningType doesn't even exist! The table is ChargeType. BUT! The code compiles! Whether it actually runs or not, we don't know because we aren't sure yet if this code is in the normal flow. But, Proparse fails. Now, I suppose it should fail because the table is not in the schema, but shouldn't it fail politely with an error message telling us so?

My only thought is that somehow a truncated version matches another table, but I'm checking on that.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tamhas's picture

Just to close this out. This

Just to close this out.

This is a Progress bug, PSC00201018, in which the compiler will accept an invalid table name qualified by a valid database name and column name, provided the column name is unique in the database. The compile correctly associates the column with the correct table and provides no error message. This is now documented in KB 000061067 and there is no plan to correct it on the bizarre notion that someone may be relying on it in production.

Proparse, however, has a problem with it because it is not a valid table.

The workaround is to correct the code to provide the correct, valid table name.

The only indicated change to Proparse would be to provide a polite error message when such a condition were detected.


tamhas's picture

James has managed to figure

James has managed to figure this out in sports2000.

Nailed it in sports2000. It only works if the field name is unique in the database. So eg:
define input parameter ipBinName like sports2000.blah.BinName.
It also only works if you predicate it with the DB name. But the table name can be whatever you like. The compiler is friendly and resolves it to the right field. So the code will probably work. But I can see how proparse would kick up a stink!

So, the only action item here would be friendlier error messages about the bad table name.


Cringer's picture

Just to confirm PSC will not

Just to confirm PSC will not be fixing this bug - PSC00201018 - as "others may be relying on the functionality". I disagree with this stance a great deal in this sort of circumstance and have made my position clear.


Will they add a compilation

Will they add a compilation warning?


Cringer's picture

They're not doing anything

They're not doing anything about it.