Re: Informix 4GL question

In article <5its0a$en6$2@news.gte.net>, Douglas Wilson <dgwilson@gte.net> writes >I've helped users who were allowed to do this sort of thing, didn't >realize they >were already 5 or 10 levels deep, then wonder why they're getting >errors. If you really want to allow the back and forth calling (it >can be useful I admit), you could >pass in some argument to only allow just so many levels of calling, and >maybe warn the user that they're already so many levels deep and using >up >system resources, and maybe to please release them. > >Douglas Wilson > >Belakimem wrote: >> >> Suppose you have an orders screen / function with an option to transfer to >> the customer screen. >> >> Suppose also your customer screen / function can transfer to the orders >> screen. >> >> Both functions can be called from a menu in main first, and both have an >> option to exit back to the main menu. >> >> Now, it is obviously possible to call customers then orders, then >> customer, then orders etc. and travel endlessly down many levels of the >> function / subroutine stack. >> >> In 4GL would this be good programming practice? What are your opinions on >> avoiding this problem, if it is one. Is it better to always return to the >> calling function before going into this spiral? >> >> Please reply to my email address as well as the newsgroup. Thank You. > I have worked on a system where this was allowed. We a) set a limit of 20 levels, however with a cursor management library and list management library this limit could easily be extended. Just change the 20 in 3 places and generate the extra cursors/list modules as required. b) Users were not allowed to see the results of previous searches i.e. they could not loop back on themselves....tricky to do and resulted in sql upto ~4 screens long at the deepest level...I know I had to debug it as when reaching level 20 and then returning to level 0 i.e. initial search it failed to reopen the cursor correctly!!! -- David Williams