Compile Errors due to confusion between database table/field

As a Workaround use

WAIT-FOR System.Windows.Forms.Application:Run (THIS-OBJECT) . 

But don't hesitate and log this issue with tech support. If you can, send them the DF file of your database so that they can easily reproduce this issue.

10.2A or 10.2A01?

10.2A. Will try with 10.2A SP1.

Do you see this as a bug then ?

saquib schrieb:
Do you see this as a bug then ?

That's something tech support should decide. My feeling is yes.

Did you try fully qualifying the Application class name (without relying on the USING statement?). That should work.

The fully qualified statement works fine, thanks!

saquib wrote:
I have the following snippet of code:
METHOD PUBLIC VOID doWait():  
     WAIT-FOR Application:Run (THIS-OBJECT). 
END METHOD.
However, this fails to compile due to the compiler confusing the word Application with table/field names in our database:
** Application is ambiguous with db.DUTY_TAX_FEE.APPLICATION and sec_data.APPLICATIONS.APPLICATION_ICON. (1762) test2.cls class selector line 99 OpenEdge Problem
If I unlink the databases from the project, then the code compiles fine. Is this a feature/bug? Any workarounds ?

My understanding is that this is not considered a bug - the ABL compiler looks to the DB first, and so resolves the reference as a DB reference, not a class reference. It might still be worth logging this with TS for reference though.

Fully-qualifying Application:Run() is the correct way to work around this.

Incidentally, OEA ran into this in the ABL it generates to run a class, when you select Run as ABL Application.

-- peter

Sounds like you may have to make a schema change.  It wouldn't be the first time that someone used a word as a table or field name and then had it turn into a keyword in a later release.  One can always get around this with the keyword forget feature, but then you can't use the feature the keyword relates to in your code, which you obviously want to do.

BTW, one of the advantages of a type prefix of table and field names is that this is unlikely to ever occur, i.e., chApplication is not likely to become a keyword.

I doubt that the keyword forget list will help for .NET type names. Application is a .NET class and run a static method.

Changing the database schema would be a rather hard measure to solve the issue. Fully qualifying the typename is an easy workaround in this case. I still believe that the compiler should be able to find out! If the compiler takes precedence for the DB schema that might be o.k., but if there is no field Application of type handle, if should be clear that Application:Run referers to some static member of a class or an instance named Application. And in the error message of the original post, the compiler took preference to a field named Applications! So an abbreaviated field name. The .NET typename would have been the closer match.

Keyword forget works just fine ... as long as one doesn't mind not using .NET!  Obviously not a solution in this case.

Full qualification is certainly a simple enough workaround, although a little tedious.

Schema changes can be tedious too, depending on how many places the field is referenced and how easy it is to match the string ... but there are tools to make it easy.

Here I think the question is, is the full qualification something that would be good practice anyway?  If so, just do it.  If not, then consider the schema change so as not to clutter the code.

Here I think the question is, is the full qualification something that would be good practice anyway?  If so, just do it.  If not, then consider the schema change so as not to clutter the code.

In general, IMO, for classes, the less qualification, the better. Compare

method private void BeforeRowInsert (sender as System.Object, e as Infragistics.Win.UltraWinGrid.BeforeRowInsertEventArgs):

against

method private void BeforeRowInsert (sender as Object, e as BeforeRowInsertEventArgs): 

The latter wins hands-down for me.

Even splitting the arguments over multiple lines is no great improvement.

method private void BeforeRowInsert (sender as System.Object,
                                     e as Infragistics.Win.UltraWinGrid.BeforeRowInsertEventArgs): 

The ABL is naturally verbose, and OO coding is too, so my preference is to reduce the verbosity as far as possible.

The issue at hand is, of course, the exception that proves the rule . Seriously, though, you're typically not going to be writing that line of code often in an application with any sort of framework or even decent inheritance, so having 1 instance of expanded notation is OK.Having said that, I'm not sure how many other members on the Application class will be invoked with regularity, other than Run() and Exit().

${CURRENCY}0.02

-- peter

pjudge schrieb:
In general, IMO, for classes, the less qualification, the better. Compare

Agreed!

Having said that, I'm not sure how many other members on the Application class will be invoked with regularity, other than Run() and Exit().

Add EnableVisualStyles() and I guess that would be most of it - but that's also usually only once per application. DoEvents() is not supported in the ABL as we should be using PROCESS EVENTS.

So, pragmatically, this is an instance where one might be inclined to use the workaround ... but in general it would be preferrable to eliminate the problem by fixing the schema.  In some cases, fixing the schema is simple because the offending field is not used in very many places.  And, as I say, there are tools for making more sweeping changes.