If the host fills the last screen with all rows, it may display duplicate values--when this value is true, logic is generated to only read the rows starting with the first one not a duplicate of the last row on the second-to-last screen.

 

For example, a screen displays history on a client in a screen on the bottom four rows, and a client with five history rows is displayed as follows:

 

Screen One History area:

 

01/01/1990   History Item 1

02/03/1991   History Item 2

03/01/1992   History Item 3

04/09/1993   History Item 4

 

F8 = More

 

Screen Two History area:

 

02/03/1991   History Item 2

03/01/1992   History Item 3

04/09/1993   History Item 4

05/06/1995   History Item 5

 

Bottom of Display

 

Note that instead of simply displaying a single row on the second screen with History Item 5 (the typical system approach), the last three items on the first screen were duplicated so that the screen is filled with the information.

 

This is OK if you are setting the ScreenReadMax value to 1 and only using the screen for an Enhanced UI generation.  But if ScreenReadMax is greater than 1 and/or this is for a web service, there will be three duplicate rows displayed / sent.

 

When DuplicateChecking is set true, the last row on the prior screen will be searched for (only when the last screen is displayed) and will be used to set the starting point for further reads of the screen.

 

While all row values are used to determine equality on the row comparison, if your data may display duplicate rows you may want to not use this option...or have the host application fixed!