Posts
The other option left was to capture the error from inside the 4GL code by checking the inquire_ingres error number after each sql statement (which does already,but I had to tweak it to also check for the specific error) and act upon it.
Since all code is grouped in frskeys (meaning that the user must press a key for the code to be activated) the whole error handling had to be shifted inside the frskey code.
Inside the frskey code there can be multiple sql statements and each one can trigger the exception.It might not be the first or second statement but it could be the 5th statement in the chain of execution. Furthermore the 'set maxio' directive is the first statement to be executed when the key is pressed,and must reset back to 'set nomaxio' on exiting or one of the conditions described later are met.
So every sql statement must be checked and the following was added after each one:
inquire_ingres (h_rowcount=rowcount,h_errorno=errorno,h_querytext=querytext,h_errortext=errortext);
When the query requires more resources than permitted then the error is captured and 'propagated' to another 4GL frame which contains the code that does the handling.
That frame prompts the user that the query is too heavy and if execution should continue, despite. If the user answers 'no' then a rollback is issued and the limiter is deactivated with 'set nomaxio' since the directive is session wide and if not deactivated it would hinder the user's work flow.
The problem was that if the user answers 'yes' ,thus ignoring the message and opting to continue with the execution, the code inside the frskey had to be repeated like the user pressing the key another time since the limiter has refused to run the query that triggered the exception and the whole frskey code has to be re-executed ,this time with the limit control deactivated.
Because letting the user re-press the key was not an option since allowing the user the margin for error means that the error will be made eventually,the whole frskey code was wrapped into two labeled while loops.The first loop had the control over if and when the process would be repeated and the inner loop was in charge of the executing the preexisting frskey code.Inside the inner loop each sql statement was been inquired with inquire_ingres and if an error was to occur then the error handling frame was to be called where it would check for if the error equals the generic number 36100 signifying that the resource limit has been exceed.
The handling procedure would then log the actual sql query that gave the error away and the error text (E_QE0203 The estimated nummber of IO requests to run this query (141)\n exceeds the IO limit (80) established for this session. The query is aborted with a fatal error. ) plus the current time and user terminal.
Then it would prompt the user as to continue or not.If not, 'set nomaxio' is reset and no further action is performed hence the user is free to continue with his work.
If the answer is 'yes' then the inner loop is exited and the outer loop re-executes the frskey code from the beginning but this time with 'set nomaxio' set so everything executes fine like it would normally do.
The ESQL error handler called by iiseterr() was used as well as to suppress the default runtime error messages appearing on the user's screen,so he is not introduced to the fact that an error occurred. All he sees is just a prompt for action.
Since all code is grouped in frskeys (meaning that the user must press a key for the code to be activated) the whole error handling had to be shifted inside the frskey code.
Inside the frskey code there can be multiple sql statements and each one can trigger the exception.It might not be the first or second statement but it could be the 5th statement in the chain of execution. Furthermore the 'set maxio' directive is the first statement to be executed when the key is pressed,and must reset back to 'set nomaxio' on exiting or one of the conditions described later are met.
So every sql statement must be checked and the following was added after each one:
inquire_ingres (h_rowcount=rowcount,h_errorno=errorno,h_querytext=querytext,h_errortext=errortext);
When the query requires more resources than permitted then the error is captured and 'propagated' to another 4GL frame which contains the code that does the handling.
That frame prompts the user that the query is too heavy and if execution should continue, despite. If the user answers 'no' then a rollback is issued and the limiter is deactivated with 'set nomaxio' since the directive is session wide and if not deactivated it would hinder the user's work flow.
The problem was that if the user answers 'yes' ,thus ignoring the message and opting to continue with the execution, the code inside the frskey had to be repeated like the user pressing the key another time since the limiter has refused to run the query that triggered the exception and the whole frskey code has to be re-executed ,this time with the limit control deactivated.
Because letting the user re-press the key was not an option since allowing the user the margin for error means that the error will be made eventually,the whole frskey code was wrapped into two labeled while loops.The first loop had the control over if and when the process would be repeated and the inner loop was in charge of the executing the preexisting frskey code.Inside the inner loop each sql statement was been inquired with inquire_ingres and if an error was to occur then the error handling frame was to be called where it would check for if the error equals the generic number 36100 signifying that the resource limit has been exceed.
The handling procedure would then log the actual sql query that gave the error away and the error text (E_QE0203 The estimated nummber of IO requests to run this query (141)\n exceeds the IO limit (80) established for this session. The query is aborted with a fatal error. ) plus the current time and user terminal.
Then it would prompt the user as to continue or not.If not, 'set nomaxio' is reset and no further action is performed hence the user is free to continue with his work.
If the answer is 'yes' then the inner loop is exited and the outer loop re-executes the frskey code from the beginning but this time with 'set nomaxio' set so everything executes fine like it would normally do.
The ESQL error handler called by iiseterr() was used as well as to suppress the default runtime error messages appearing on the user's screen,so he is not introduced to the fact that an error occurred. All he sees is just a prompt for action.
Comments