How to READ/FIND Adabas file in breaks?
I am reading an Adabas file with certain criteria. I am reading only 10 records in one time ( In one Read/Find loop) and coming out of the loop…
Now suppose the file is having 100 records satisfying my criteria. In my first Read/Find loop 1 to 10 records will be read, in the next loop how can I read 11 to 20 records, 21 to 30 records and so on…
When you exit a loop … you exit a loop.
You will have to remember where you left and where you need to start
the next loop, check into the RETAIN clause for FIND (it will help you to
not having to create the result set over and over again), and the
STARTING WITH clause for FIND and READ.
1 Like
I think if I save the *ISN (in #ISN) of last record of every loop, the next loop can be started using WHERE *ISN > #ISN. Can it work correctly for all READ/FIND loops?
NO, because you can NOT assume ISNs to be ascending when you read / find by descriptor !
That’s why I pointed you to STARTING WITH
1 Like
I am guessing that this question, in conjunction with your question on Maps, is indicative of an application where, for example, a user wants to scroll through all orders between two dates. Suppose there are 50 orders that satisfy the dates constraints. I am guessing you have designed a screen with ten lines (orders) for display and possible selection.
If this is indeed what the application is all about, and if a user would typically scroll through all (or at least most of) the records, it would probably be easier to code, and hence to maintain, your program to read all the records that satisfy the criteria and store them in an X-array. You could then control the starting and ending subscripts in the Map. Even better, you could also use Processing Rules, so that all the scrolling takes place in the Map, thus eliminating going back and forth from the program to the Map.
You can extend this concept to deal with even really large sets of records that satisfy the specified criteria.
steve
1 Like
Yes Steve! you got it right. I have already implemented an array of 1000 occurrence but Natural can’t read more then 1000 records in one READ loop in online mode. If there are more then 1000 records satisfying a criteria or user wants to read all the records in that case I’ll have to save last record address, close the loop and read again starting with the last address I stored previously.
isn’t quite right, this is not a “natural” limitation, it’s one the Natural administrator sets.
And this limit is rather high, it doesn’t make sense to read-ahead even 1000 records “just in case”,
how often will a user really page forward 80 or 100 pages and then back again ?
This is bad design, and if you need to take care of “scrolling” anyway - set the limit lower.
1 Like
I think 100 is the best size of array and in case user wants more then 100th record, I can save ISN of every 100th record and use STARTING WITH #ISN for fetching next 100 records .
That sounds a lot more reasonable, yes 
1 Like
Thanks a lot Wolfgang and Steve for your so precious suggestions. 
when working with a READ statement, you may be able to use the “STARTING WITH ISN” clause. See http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat822mf/sm/read.htm.
Note that the ISN you supply is not returned, but the next ISN is. This means you can readily keep track of the last ISN read (note that you also have to keep track of the last descriptor/superdescriptor value read) and supply those as the starting point when you re-enter the loop.
FIND loops, while not as easy to reposition, also shouldn’t be returning very large sets of results, particularly for online applications or you are wasting a lot of search effort.
That would work for an unsorted find - because the default FIND-sort is by isn.
But as Douglas Kelly said, there’s maybe a better solution…
browse is done based on a key rt? save the key details as #Key depending upon whether up or down is pressed, example if next is choosen then move the key details of the last record on the screen to #Key and the 1st record if prev is choosen.read with starting from #key ascending / descending depending on what is selected. ignore the first record as it will be repeated. This will hit the database every time you hit prev or next
Unnecessary. You can avoid the overhead of reading and rejecting the starting record by following Douglas’ advice and coding the STARTING WITH ISN clause.
That would only work if the key is unique, right?
But it would be fun when you can’t scroll any further than Smith or Meier because
there are more than a screen full - good learning effect
yes it will work only for unique keys. sorry i forgot to mention
Well,
To be more precise, “…that would only work if the key does not repeat itself more times than the scrolling screen size”. It`s unnecessary to require the absolute uniqueness of a key, as I think…
I think it would be very confusing for the user, that “page down” is only half a screen sometimes …
Is that really an issue when re positioning using the last ISN displayed within a non-unique descriptor value (see Douglas Kelly’s response)?