So I've been trying to get proparse working on my code base, and one of the issues I've come across that really messes with it is something I would consider to be a cause for throwing a compile error, but doesn't. Before raising it with support I wanted to check I'm not missing something.
Against sports2000 consider the following:
PROCEDURE DoesThisWOrk:
define input parameter ipBinName like sports2000.Bin.BinName.
end.
This is absolutely fine. But if I change the table name as follows it still compiles:
PROCEDURE DoesThisWOrk:
define input parameter ipBinName like sports2000.WhateverTheHellIWant.BinName.
end.
This is because BinName is a unique field in the database and therefore the compiler can resolve the field properly. Interestingly if you remove the DBName from it it throws an error on compile.
We've got a few cases where someone in a rush has fallen foul of this because most of our fields (except keys) are uniquely named and thus the compiler can resolve what you mean. But understandably proparse throws a right wobbly because it can't find the table in the schema.
Is this a compiler bug? Is it worth raising it with support?
Oh yes, please ignore the fact that it's terrible practise to use LIKE ;)
> it's terrible practise to use LIKE ;)
Why?
This is definitely a bug. Please, submit a bug via Support.
>> it's terrible practise to use LIKE ;)
> Why?
Because that's when you risk running into this bug.
Other statements where fully qualified references can show up seem to be raising sensible compiler errors:
display sports2000.WhateverIWant.BinName.
if proversion = sports2000.WhateverIWant.BinName then message "that's odd".
> Because that's when you risk running into this bug.
find first customer.
display n.
Progress does not treat the abbreviated names as a bug but the consequences can be even more serious. ;-)
Yes, absolutely a bug and I think a fairly horrid one.
The problem with LIKE is that it creates a false dependency. I.e., it implies a connection to the database whether or not there is any reference to that field in the procedure.
> The problem with LIKE is that it creates a false dependency. I.e., it implies a connection to the database whether or not there is any reference to that field in the procedure.
Do yo mean the following from online help for "DEFINE VARIABLE statement"?
If you reference a database field in a LIKE option in a DEFINE VARIABLE statement, DEFINE TEMP-TABLE statement, DEFINE WORK-TABLE statement, or format phrase, the database containing the referenced field must be connected at both compile time and run time. Therefore, use the LIKE option with caution.
But documentation is incorrect: a LIKE option needs db connection only at compile time.
RCODE-INFO:DB-REFERENCES and RCODE-INFO:TABLE-LIST do not refer to db/table used in the LIKE option and rcode can be run without db connection.
If the run time connection were mandatory, at least it would be a real dependency, but, it is a false dependency. Analyzing the code, you *think* there is a connection, whether there is one or not. It is unnecessary baggage of default labels, and such as well. There is just no reason for it.
> There is just no reason for it.
I use a LIKE option with VST fields all the times.
1. I don't need to know if the field type is integer or int64 in the Progress version the program will run under. I don't need to know if updatevst was run again a database or not.
2. I use a LIKE option for a self-documenting:
define var vTableReads LIKE _TableStat._TableStat-read.
The statement clearly explains that the variable will store the table reads per whole database. Not the user's table reads. Not the record fragment reads.
> you *think* there is a connection, whether there is one or not.
I just don't think about a LIKE option as it's being a db connection.
I always uses DICTDB alias with VSTs... except in the LIKE options. Just to emphasize: it's not a connection.
Reply by Thomas Mercer-HurshIf the run time connection were mandatory, at least it would be a real dependency, but, it is a false dependency. Analyzing the code, you *think* there is a connection, whether there is one or not. It is unnecessary baggage of default labels, and such as well. There is just no reason for it.
Stop receiving emails on this subject.Flag this post as spam/abuse.
If one changes the datatype of a database field, one still has to visit all the code where that field is referenced because there may be local variables whose type also needs to be changed.
Come to my PCA talk for an example of a report to help this process for integer to INT64 changes.
Reply by Thomas Mercer-HurshIf one changes the datatype of a database field, one still has to visit all the code where that field is referenced because there may be local variables whose type also needs to be changed.
Come to my PCA talk for an example of a report to help this process for integer to INT64 changes.
Stop receiving emails on this subject.Flag this post as spam/abuse.
For me a LIKE option means its own datatype. For example:
define var vTableReads LIKE _TableStat._TableStat-read.
define var vMyTableReads LIKE _UserTableStat._UserTableStat-read.
If somewhere in the code I would see: "vTableReads = vMyTableReads" then my personal rules will treat this as the "incompatible data types" regardless of data types of the original VST fields.The values from variables defined LIKE _TableStat-read can be assigned only to the variables defined with exactly the same option. Both the "mileage" and the "price" fields can be of DECIMAL type but logiacally it's not allowed to exchange the values between these fields.
The future Progress versions could change the types of VST fields to INT128 but the code will still work without any changes.
Just to close the loop - Support have identified that this is this bug: knowledgebase.progress.com/.../P131788 and as per usual they will not be fixing it because "some people may be relying on this functionality". Which in this case, in my opinion, is terrible because the code is actually wrong.
At the very, very least they should give us a compiler warning, but the idea that someone is depending on this is outrageous.