This behavior is seen in 11.7.5 and earlier. Say there is no such field poney in the customer table:
DEFINE TEMP-TABLE ttcustomer NO-UNDO LIKE customer.
CREATE ttcustomer.
FIND FIRST customer.
BUFFER ttcustomer:BUFFER-COPY(BUFFER customer:HANDLE, "poney").
=> raises no error at runtime. Pretty dangerous if the except-list has a typo (hardcoded or in a variable)
On the other hand, with static programming we get this compile time error which is safer
BUFFER-COPY customer EXCEPT poney TO ttcustomer
** Unknown Field or Variable name - poney. (201)
11.7 now offers a significant improvement with strict compilation warning and errorsd. Are there ideas to provide stricter checks at runtime to detect cases like this one, especially around the record buffer methods?
I agree with you. IMO, this is just a bug. There seems to be a development philosophy that assumes it is OK to ignore some mistakes. Oh - you didn't want that field? Well, it doesn't exist anyway, so I guess we can just ignore that! No.... It means you are not excluding a field that you meant to exclude. You could do the same for a startup parameter that doesn't exist (due to typo). Oh... there is no such thing, we'll just ignore it. No... It means you are not getting the behavior you want.
Of course, fixing this could cause a change in behavior if some ABL developer never noticed their mistake. It would be a discussion we'd have to have.
I agree with you. IMO, this is just a bug. There seems to be a development philosophy that assumes it is OK to ignore some mistakes. Oh - you didn't want that field? Well, it doesn't exist anyway, so I guess we can just ignore that! No.... It means you are not excluding a field that you meant to exclude. You could do the same for a startup parameter that doesn't exist (due to typo). Oh... there is no such thing, we'll just ignore it. No... It means you are not getting the behavior you want.
Of course, fixing this could cause a change in behavior if some ABL developer never noticed their mistake. It would be a discussion we'd have to have.
Yep a bug, however, better to have KB of known misbehaviour than risk a critical application failing because of new runtime enforcement.
Simple scenario: Field "poney" was once in the DB Schema and is no longer. Runtime is acting as expected by ignoring the now defunct field without code modification. Yes, Laura they should have done a code scan and got rid of the reference, hey maybe it was written "PONEY" in the code, and their case sensitive search failed.......
[quote user="Laura Stern"] Of course, fixing this could cause a change in behavior if some ABL developer never noticed their mistake. It would be a discussion we'd have to have. [/quote]
Add it to the strict compile option?
Tim, great idea!
glad you like it. :)
For runtime there could be a "strict" switch that could be enabled for testing for cases like this and other things that should go away but are being retained for legacy compatibility.
Yeah. This concerns dynamic methods, so those would need a runtime strict mode to catch issues.
There's a few other things such a runtime strict mode can/should catch, like the fact that you can add illegaly-named fields to a dynamic temp-table. (knowledgebase.progress.com/.../000031232).
And using fields that are not in FIELDS for a new query or find, only get logged to DB log file, don't throw error :(
Sample from db log file:
P-93844 T-103544 I TSRV 4: (8826) Field Drawing_barcode from Drawing record (recid 191375) was missing from FIELDS phrase.