I am a big fan of using correct case, expand keywords and indentation, but for the Indentation I would love to have it in another way, is that possible?
FIND FIRST hendelseRSTO NO-LOCK WHERE hendelseRSTO.ans# = hendelse.ans# AND hendelseRSTO.son_aar = hendelse.son_aar AND hendelseRSTO.son_lnr = hendelse.son_lnr AND hendelseRSTO.Jour_lnr = hendelse.hend_lnr AND NOT hendelse.Slettet NO-ERROR.
I would love:
FIND FIRST hendelseRSTO NO-LOCK WHERE hendelseRSTO.ans# = hendelse.ans# AND hendelseRSTO.son_aar = hendelse.son_aar AND hendelseRSTO.son_lnr = hendelse.son_lnr AND hendelseRSTO.Jour_lnr = hendelse.hend_lnr AND NOT hendelse.Slettet
Is it possible ?
FOR FIRST is even worse.
Try this with EACH and then replace EACH with FIRST:
for EACH customer no-lock where discount > 10 by discount:
display cust-num name discount.
If you expected that result for FIRST I'd be interested in how you would explain it to a user.
It is not possible to post good looking code examples on communities :(
And you are still using FIRST.
Please be aware that there are valid reasons to use a find first - it's not always wrong as has been suggested.
Say you have an accounts package and you want to display the oldest outstanding transaction for an account in an enquiry.
You can do a find first on the transaction table for the account where the status is open using an index that contains account, status and transaction date.
I believe I thought of the unknown value and that I was technically right.
Try with this: Did I really miss something?
DEFINE TEMP-TABLE hendelse NO-UNDO
FIELD Slettet AS logical
INDEX Slettet Slettet.
hendelse.Slettet = ?.
FIND FIRST hendelse WHERE NOT hendelse.Slettet NO-ERROR.
MESSAGE AVAILABLE hendelse
Of course it's not ALWAYS wrong -- just 999 times out of 10 ;) Finding a few cases where it is ok does not make it valid to glue FIRST onto every FIND. THAT behavior is what I claim is ALWAYS wrong. It is NOT appropriate to ALWAYS code FIND FIRST.
Although, to pick nits, in your examples in a client/server environment I would use can-find() because it doesn't pull the records across the network ;)
To reinforce what Tom has said ... this being an area where we agree! ... one of the key bad things about FIND FIRST is not so much that the program will behave incorrectly as what you are communicating to any future developer who has to deal with the code (which might be you, 10 years later, when you have forgotten everything about the code. If you find the first record in a group and treat it specially, then you have violated normal form. So, CAN-FIND is fine because you are merely determining whether a given set is null or not and you don't care about the count as long as it is not zero. But, the minute you so much as use a value from the record which happens to come first, you are treating that record as special and are violating normal form. Storing something in it is even worse.
And, if the specified criteria are sufficient to uniquely identify a record, so the issue about one of a set does not exist, then using FIND FIRST communicates to the later programmer that there is a set, which is not true.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com