# which one is efficient... Find NUMBER or FIND (1)

My intention is to find whether there are any records in a particular file.

I am having 1000 records with a particular key value in a file. I just need to find whether there are any records in that file with the key value or not.

which one is efficient… Find NUMBER or FIND (1) ??

``READ (1) PHYSICAL``

because it does, inc contrast to FIND, not need to create an ISN list.

1 Like

Wolfgang, I’m curious - so in what kind of scenario is FIND best suited?
Also, is the assumption that FIND (1) will only read single record , and FIND NUMBER will read every record with a matching key (hence very resource hungry) a valid one?

Hi, thanks for replying. I understand READ (1) PHYSICAL can be used to find whether at least one record is present in the file.

To bring more clarity in the query I posted, I wanted to know whether a record with a particular key is present in the file or not ?

First; for Kannan; FIND NUMBER does not read records so long as there is no WHERE clause, just a WITH clause.

While the difference is probably miniscule, HISTOGRAM with starting from and ending at clauses (or a loop limit of (1)) might be almost as fast as FIND NUMBER, but, since FIND NUMBER does not start a loop, and HISTOGRAM does, my guess is that FIND NUMBER would be slightly faster.

BUT, as noted, the difference is likely to be quite small.

Despite the truth in what Steve Robinson says, if I were to recommend to a new programmer to Natural the approach to take, I would advise use of HISTOGRAM over FIND NUMBER. To risk issues that stem from a programmer who is learning new syntax to remember “is it WITH or WHERE I should use?” and issues stemming from the wrong choice, it is safest to get used to doing this:

HIST1.
HISTOGRAM myview descriptor #value #value
END-HISTOGRAM
IF *NUMBER(HIST1.) NE 0
END-IF

You obviously don’t need to use any commands that will return a record if you are only looking to see if a record exists or not based on an inverted list entry being present. HISTOGRAM and FIND NUMBER do that by only traversing the UI and NI blocks and not accessing AC or DS. HISTOGRAM does create a loop which means it goes back and gets the next inverted list entry, which is minuscule additional overhead over a properly coded FIND NUMBER, but newer programmers are more likely to get this right 100% of the time.

The same can be said about FIND (1) vs READ (1) when the intent is to read just 1 record based on a unique descriptor… the FIND (1) is more efficient in this case when properly coded (avoiding the use of WORK part 2 and complex search algorithms), but problems come with liberal use of FIND loops where knowledge of the data is not clear, and you eventually will see FIND (1)'s that build massive ISN lists only to return the first one to Natural, discarding the rest.

This is by no means meant to be derogatory, as when I first starting programming in Natural in 1988, we basically were told to never code anything with a FIND, and to limit ourselves to READs and HISTOGRAMs. I see the wisdom in that for those new to Natural, but the more experience one gets to where one knows not only what Natural is doing but also what ADABAS is doing with the resultant direct calls, then I have no problem with advanced Natural programmers using the FIND / FIND NUMBER structures where most appropriate.

Well, I’m really impressed by that “ROCK SOLID” advice (using of HISTOGRAM over FIND NUMBER)

Perhaps, HISTOGRAM (1) - mentioned by Steve by the way - would be at least as fast as a simple HISTOGRAM.
Just my 2 cents to this “highly methodological” discussion

There is a flaw in the HISTOGRAM examples provided - they both use THRU/ENDING AT.

Brian touched on the concern of non-unique descriptors. In Deepak’s example, what if all 1,000 records had the same descriptor value, say 2?

``HISTOGRAM (1) file FOR de = 1 THRU 1  /* Adabas returns 1,000 for value 2; Natural rejects the count``

Here’s the example I use in my training classes:

``HISTOGRAM (1) file FOR NAME = 'SMART' THRU 'SMART'   /* no SMART; Adabas returns SMITH; Natural rejects the count``

Adabas expends quite a bit of effort to determine the number of Smiths. I recommend the TO clause to prevent the unnecessary processing by Adabas.

``HISTOGRAM file FOR de = #VALUE TO #VALUE``

Then there is no need for the loop limit (1).

Of course, if the descriptor occurrences are high, as with Smith, use a READ (1) FROM/TO instead of HISTOGRAM.