4gl version 4.2

There are several problem we have come across since upgrading to the new Y2K compliant Informix version 4.20.UC1. Informix has not deemed these problems serious enough to provide solutions to us, although they are preventing our clients from performing they daily operations as needed. 1) When performing a "construct", it is now necessary to 1st initialize the global int_flag variable to false. Otherwise, if this flag has been set to true from any other area of the program, the query result string will contain a null, and cause the querying action to bomb with an sql syntax error. Informix has made this change in order to not return a query string when the user has interrupted the construct. However, we do not find this helpful, as we can program in "on key" code within the construct to handle user cancellation of the construct. Informix is not actually trapping the interrupt key-stroke, but just testing on the global int_flag, which mau have been set for any number of reasons outside the scope of the construct. In our situation, the user is not even attempting to cancel out of a construct, and yet the program will bomb with the sql error, if int_flag happened to be true. We have asked Informix to test for actual key-stroke instead of testing global int_flag, but their response has been that they will change their documentation to state that int_flag must be initialized to false preceding each construct statement, from now on. This means we must change all of our existing source code (in our case, over 200 instances of construct), and always remember to initialize int_flag for any new construct code we write, for a feature that we do not even find helpful. 2) Informix has changed the behavior of input array, such that if any field in a row has a value set to it, even a non-input field, the row will be considered "touched", and counted in Informix built-in function- arr_count(). There is no way of removing this row programmatically, only by user pressing delete key. On older versions of informix, we would display a sequential line number to a non-entry field of a row, before the user would make any input. This display did not cause Informix to internally count the row; if the user arrowed up from such a row without making any entry on that row, Informix would AUTOMATICALLY clear that row (clear the line number displayed) and arr_count() would not count it. YET, if the user tried to arrow down below that same row, Informix would intelligently perform screen form validations on other fields of that row, and prevent the user from having 'empty' rows between filled rows (eg. if there was a "not null" field defined in the row). And, if the user pressed the accept key on such a row, arr_count() would not count it, and screen form validations would not be performed on that row (this behavior is desirable). Under the new version of Informix, the same program will not clear the row when user up arrows to the row above. If there are field validations that exist in the screen form for fields of the row, they will be enforced when the user attempts to leave the row, such as by moving up to prior row, or even if pressing the accept key; eg. the user will get - "This field requires an entered value" message if there is a not null attribute defined in the screen form for a field in the array. We now have a lot of work to do for existing input array, as well as any new code we write, since we can no longer combine the benefits of screen form validations with displaying guidance information, such as line numbers, on a row not yet entered by the user. We must now either code in all the validations within the 4gl, when the user has actually made an entry to any field on the row, or we cannot pre-display information on a row until the user has made an entry. Informix has made this behavior change as a bug fix to the following scenario - previously, if the program 4gl code pre-filled fields of an input array row, as defaults, the program did NOT count the row if the user left the row from a field that did NOT have data filled in it (even if fields to the left and fields to the right had data filled from the 4gl code, and those fields were "enterable"). I have made the suggestion to Informix to resolve this conflict between "fixing" their original bug, and not "breaking" our code that always worked before, by NOT counting a row as touched, if only a non-entry field has been filled. This would help us to continue to display guidance line numbers for the user when reaching a new row, but not enforcing screen validation until an "enterable" field has data filled in it. Informix, at this time, is not responding to this problem as a bug that they must address, yet for each instance that our clients get a message "This field requires an entered value" when trying to exit an input on a new row, we must spend at least 3 to 4 hours re-coding the input array. 3) Informix has now allowed the "after row" block to contain a "next field" statement that will return input to a field of the "current" row. Previously, "next field" would place the cursor in that field on the row that the input direction landed (eg. on next row if arrow down was pressed). We have already come across 2 problems when making use of this new change: a) If a row was just deleted by the user, and there is a "next field" in the "after row" block, input from keyboard will freeze; only function keys are "functional"; any other keyboard entry will simply cause the program to beep; this behavior appears to match that of a "display array" - which does not allow keyboard strokes, except function keys. Informix has not yet given us an answer on how they will resolve this problem. b) If the "next field" in the "after row" is a "non-input" field, but is ALSO NOT the last input field of the row, (in my case it was the 1ST field in the input record), the "before field" code for that field * WILL * get executed, but the program will then immediately skip all other input fields on that row, and jump straight to the "after row" block again. I have not yet at this time, reported this problem to Informix. This particular code caused my program to go into an endless loop. If anyone else has experienced such problems, please contact us so that perhaps Informix will tend to these matters in a more serious manner. Thank You, Judy Stern email: judy@astrainfo.com