Use of Correct indentation - Eclipse

You can get hold of an old Progress program called beauty.p and modify it to indent anyway you like.

Personally I would indent like this:

FIND FIRST hendelseRSTO  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-LOCK NO-ERROR.

religious war time! :-)

obviously you want:

FIND FIRST hendelseRSTO

  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-LOCK NO-ERROR.

1. an indent should only ever be ONE tab

2. AND / OR as query predicates determine the query - an AND at the back is like a Borat NOT joke.

Stefan, I have to agree with you here :-)  but How to get it like that in eclipse?

My way is close to Stefan's but with NO-LOCK as early as possible

I wish it would be possible to align stuff to the right side of the WHERE word and the equal sign like in for an ASSIGN statement

   Perhaps I should revise my standard to dedicate a last line for the NO-ERROR

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   hendelse.Slettet      = FALSE NO-ERROR.

By the way, the following is bad for performance because progress cannot pickup an index for this:

 AND NOT hendelse.Slettet

people should do this:

 AND hendelse.Slettet = FALSE

Kind regards

/S

hendelse.Slettet = FALSE is not the same as NOT hendelse.Slettet

Technically you are right, Scott, but anyone who relies on the unknown value of a logical deserves to be shot ;) M Lacroix is correct in saying that using equality is more efficient than using NOT though.

All examples above are incorrect because of the 'find first' though... ;)

@james: correct. Didn't Tom suggest to change 'FIND FIRST' to 'FIND ANY'?

I use find first myself but I've forgotten why! I've been using it for nearly 30 years.

In the back of my head I've a half-notion of it being quicker.

I couldn't justify it now but it hasn't bitten me on the bum either in all that time.

find first is fine if you genuinely couldn't care which record you get if there are multiple. I suppose it's fine if you're searching on a unique index (although that might change in future). The point of find without the first is that if you have multiple results satisfying the where clause you handle that and inform the user that something is wrong rather than making an assumption. I always used find first before, and likewise was never bitten. BUT, having changed my ways to omit the first I have encountered a number of situations where I /could/ have been bitten.

OK, but should I use a FOR FIRST instead?

Update from Progress Community <4U3LU3OEGM9Z-jpg_2D00_70x70x2-jpg> James Palmer find first is fine if you genuinely couldn't care which record you get if there are multiple. I suppose it's fine if you're searching on a unique index (although that might change in future). The point of find without the first is that if you have multiple results satisfying the where clause you handle that and inform the user that something is wrong rather than making an assumption. I always used find first before, and likewise was never bitten. BUT, having changed my ways to omit the first I have encountered a number of situations where I /could/ have been bitten. View online   You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here. Flag this post as spam/abuse.

For first will still mask the fact there are multiple results to a query. And is, in fact, even harder to mitigate against. find customer where... will not have a record available and you can test for ambiguous if none is available. You immediately know either your query is wrong, or your data is wrong.

The advantage of FOR FIRST over FIND FIRST is the ability to use the FIELDS phrase.

But as James says, probably best to omit the FIRST.

We probably need a thread devoted to the evils of FIRST.

999 times out of 10 it is being used without any thought by a programmer who either thinks it is required because they have never seen a FIND without it or because they once thought they heard that it was faster and faster is always better.

For the record: FIND FIRST is only faster if it is also wrong.  If FIND FIRST makes your code faster it is because you do not have a unique index to go with your WHERE clause.  If you do not also have a loop and some FIND NEXT statements then you are ignoring the rest of the result set.  That means that you are violating 3rd normal form.  Either you are saying that the  FIRST record has a magical attribute that the 2nd, 3rd etc do not or you have redundant data.  If OTOH you do have NEXT statements then one has to wonder why you are not using FOR EACH?

The overwhelming majority of FIND statements do not need and do not benefit from FIRST.

Some FIND FIRST statements are subtle bugs that will probably never be tracked down and will intermittently bother users forever.

A small number of FIND FIRST bugs are catastrophic.  But still very hard to uncover.  Especially when nearly every FIND has a specious FIRST glued onto to it.

FIND FIRST everywhere is a bad coding habit.  Don't copy bad code.

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.

end.

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.

CREATE hendelse.

hendelse.Slettet = ?.

VALIDATE hendelse.

FIND FIRST hendelse WHERE NOT hendelse.Slettet NO-ERROR.

MESSAGE AVAILABLE hendelse

  VIEW-AS ALERT-BOX.

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.