Conflict between class and Database table

Posted by James Palmer on 28-Oct-2014 03:51

Came across an odd one in 11.2.1 at the weekend. We added a table to our Database called EnvironmentControl. Elsewhere in the application we have classes with "USING System.Environment" statement in them. Subsequent to adding the new table to the database these programs fail to compile wherever there is "Environment:xyz" due to a conflict with the new table name. 

Is this a known issue? Is there a fix for this? We've worked around it by qualifying the references properly as "System.Environment:xyz" but it's not ideal as it's meant visiting a lot of code. 

OpenEdge Development - Forum

All Replies

Posted by Frank Meulblok on 28-Oct-2014 04:58

Don't have a 11.2.1 on hand to test right now, but this seems to be solved in 11.3.3 at least.

Code:

USING System.Environment.

message Environment:CommandLine.

 

Compiles and runs just fine when I'm connected to a database with a table called EnvironmentControl, which has a field called "Commandline"

Posted by James Palmer on 28-Oct-2014 05:07

That's very kind of you Frank. Thanks for testing.

Posted by Simon L. Prinsloo on 28-Oct-2014 05:58

[quote user="Frank Meulblok"]

Don't have a 11.2.1 on hand to test right now, but this seems to be solved in 11.3.3 at least.

Code:

USING System.Environment.

message Environment:CommandLine.

 

Compiles and runs just fine when I'm connected to a database with a table called EnvironmentControl, which has a field called "Commandline"

[/quote]

It will fail if you add a field to any table and start the field name with "Environment".

The compiler resolve all tokens in a specific sequence and class names are resolved last. If the class name can be resolved as an abbreviated field name, it will resolve to the field name and cause an error. Progress says it is to "prevent old code from breaking" and for that reason they cannot move the evaluation of possible abbreviations after class names.

In my opinion that is nonsense, because I can thing of only two ways that it would "break old code":

  1. The class has no name space / package and match an abbreviated field in code. But having a class in the root package is bad practice and it should be fixed. 
  2. Abbreviating field names in production code is also bad style, but it will keep compiling until someone change the source and introduce a USING that causes a conflict with the abbreviation. Since the programmer has the source open, fixing the bad code (abbreviations) are not an issue to me.

As for an EXACT match between a field name and a class name, that is unfortunately a case where the field name will take precedence and you will need to fully qualify the class.

Posted by James Palmer on 28-Oct-2014 06:04

Thanks Simon,

Yes I agree that if it is an exact match then it should cause a problem. Maybe there could be a parameter that says I want Progress to only use exact matches for variables, tables and fields?

Posted by Simon L. Prinsloo on 28-Oct-2014 06:19

I would prefer that field abbreviations are not allowed, unless a parameter that says: "Please allow table and field name abbreviations" is present, more or less like you need -v6q to restore old index rules...

Posted by Simon L. Prinsloo on 28-Oct-2014 06:31

I've added an Idea for this.

Posted by James Palmer on 28-Oct-2014 06:39

Happy to vote in favour :)

Posted by Frank Meulblok on 28-Oct-2014 11:38

Ah yes, Indeed it's the field names that trip things up, not the table name... And yes, if I add a field that starts with Environment that also trips up the 11.3.2...

This thread is closed