FIND FIRST item.
and
FIND item 1.
?!?!?!
FIND item 1.
doesn't work, but
FIND item.
does.
I see work both on the Sports2000.db sample DB of Openedge.
FIND item1 is documented as.
FIND record constant.
Where constant is the value of a single component unique, primary index for the record you want.
So for sports2000.item the compiler translates this to
FIND item WHERE item.ItemNum = 1.
While FIND FIRST Item returns the same record, but that's just by "accident" as FIND FIRST returns the first record ordered by the primary index. So FIND FIRST Item and FIND Item 2 will not return the same row.
I was so used to FIND FIRST Customer, that I overlooked that the question was for item. Please forgive my fingers.
Message was edited by: Mike
Mike Fechner
Talk about a blast from the past....
That would also explain why it didn't work for my (current) production table.
Well, I never use the FIND record constant in real life code. Just in these little but very efficient ad-hoc queries. Specifying the key fields makes the code just so much better readable. And creates more security, in case you change the primary index ever.
So, to wrap up:
1. While FIND .
2. It is generally regarded that FIND FIRST should also be avoided except in special circumstances and structures. If the WHERE clause actually specifies a unique FIND, the the FIRST keyword is deceptive since it suggests an expectation of multiple records. Since there is no BY clause for a FIND, if the WHERE clause specifies a non-unique find, there there is no assurance which of the records will be returned and treating one of the group as different from the rest is bad relational design.
For completeness cite from "OpenEdge Development: ABL Reference"
FIND
The value of a single component, unique, primary index for the record you want.
"FIND customer 1."
ABL converts this FIND statement with the constant option of 1.
"FIND customer WHERE cust-num = 1."
The cust-num field is the only component of the primary index of the customer table. If you use the constant option, you must use it once in a single Record phrase, and it must precede any other options in the Record phrase.
It does it for you, but you shouldn't do it. I.e., it is bad programming practice to use this form since it is less clear what you mean and places the code at risk should the primary index change in the future.