A programming problem

Hello, I have some questions. Please post your answers/comments or follow-up questions to the List. I would like to know if any of you have coded a 4GL program that operates like the SQL product's PERFORM menu, letting your users update records in the current list and add new records to the current list. The 4GL menu would look like this: Sample_menu: Query Next Previous Add Update Remove The operation of your 4GL program would be like that of PERFORM. After doing a query, the first record of the current list is displayed. Users can view the other records using 'Next' and 'Previous'. Users can add a new record to the end of the current list by using the 'Add' option. If a record is updated and the user goes to the next record and then returns to the previously updated record, the changes *are* displayed, because the changes to the record are made in the current list (as well as the table). I have coded a 4GL routine similiar to PERFORM in which the users can do every- thing except the 'Add' routine. Within the same source file, I have placed my query function at the top (this query function runs the CONSTRUCT statement). Placing the query function at the top of my source file lets me use the same scrolling cursor in all the other functions. The function containing the menu is second in my source file. When the query option is called, control is passed to the function at the top of the file. I use some flags to check whether a current list exists or not. When the 'Next' or 'Previous' options are selected, I increment a counter that is used to keep track of which row the user is on. When an 'Update' on a row is done, I call my routine with the INPUT statement (which is contained in a separate source file). After program control is returned to the Update function, whether the user aborted the update or not, I close the scrolling cursor, then open it again to get a new current list, and lastly do a FETCH ABSOLUTE row_counter INTO program_array.* to redisplay the exact same row that the user just updated (or aborted updating). A similiar operation is done for the 'Remove' option with some extra code in case the user deletes the last row in the current list. There's only one little problem I'm having with this program: The update and remove options run slow. As best I can tell, the progam slows down when the cursor is closed, then opened again, and the FETCH ABSOLUTE is done. This has occurred on a newly created table with only 3 records in it! *** QUESTIONS *** What's causing the 'Open' cursor or the 'Fetch' statement to run so slowly? Should I code an UPDATE STATISTICS statement before reopening the cursor? What exactly does the Update Statistics statement do? Should I use an index on the select statement that I prepare from the CONSTRUCT statement? Have you coded a program that gives your users PERFORM-like capabilities, including the ability to 'Add' records to the current list? Thanks in advance for your reply. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Baker U.S. Army Information Systems Command - Lex Lexington - Blue Grass Army Depot Lexington, KY 40511-5109 Phone: (606) 293-3644 or 293-3743 E-mail: jbaker@lexington-emh2.army.mil DSN: 745-3644 or 745-3743 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=