Report Desk: Understanding Timeout and Strikeout Scenarios
Versions: Elliott V8.6 and Up
Background: Report Desk Impact on the Database Server
Report Desk sessions are run on the user's workstation -- that is to say, the creation, formatting, and delivery of the reports are done on the client machine. Whenever report data is needed, a request is shipped off to the database server (usually a separate, more powerful computer), where database access occurs and the results are sent back to the client for processing. This type of client/server processing spreads the workload among multiple computers while minimizing network traffic.The request to the server is limited by a timeout on the client side. If no response is received from the server after the specified number of seconds, the client software assumes the server will not respond and returns control to the user who can decide how to handle the timeout. Ideally, the server will see that the client has timed out and will stop any further processing of the request. But there are some situations where the server will continue processing the request even though the client has given up. Obviously, Elliott tries to minimize those scenarios.
Two Timeout Values
Elliott specifies two timeout values:- An initial number of seconds for processing a report.
- An extended number of seconds that can be used to retry a report that has just timed out.
Each report can have its own unique timeout values that will override the global values. See the following article for details: Report Desk: Font, Margin and Timeout Overrides . A privileged Report Desk user (one who can modify reports) can specify these overrides in the Report Designer as needed.
Two Strikes and You're Out!
Most of the time, your report requests will process quickly and have minimum impact on the database server. However, it is possible to start long reports that can negatively impact the server. When a timeout occurs, or when a user cancels a report during the initial database record selection process, it is possible for an unusable database request to continue to run on the database server.
When a timeout occurs, or when a user cancels a report during the initial database record selection process,
the current Report Desk session is charged with a strike. If the strike count reaches two strikes for the session, the Report Desk session will be cancelled and the user will be returned to the list of reports. Elliott cancels the session to help prevent the user from unwittingly flooding the server with unusable requests.
Note that whenever a report completes its initial record selection, the strike count is reset to zero.
Accumulating Strikes
When a timeout initially occurs, a message similar to the following is shown:
Notice "STRIKE ONE!" in the title of the message. The timeout number of seconds is shown on the first line of the message (here set to 2 seconds for demonstration purposes). At this point, there is one strike against this report session.
If you press the Yes button, the report will be retried with the extended timeout number of seconds. Pressing No returns the user to the input parameters screen. In either case, the session has one strike against it.
Another way to get a strike is to press the Cancel button during the initial record selection process. Doing that will result in this message:
If you press Yes, you will get a strike.
When you get two strikes against the session, you will get this message:
Notice "STRIKE TWO!" in the title of the message. After you press OK, the Report Desk session will terminate and you will return to the list of available reports. There is nothing to stop the user from trying to run the same report again. However, it would be better to change one or more input parameters to reduce the time to produce the report.
JEG
EL860RD, ELRW_SYRPTUDR