Laserfiche WebLink
<br />00'0 084 <br /> <br />Setting a call <br /> <br />Releasing a call <br /> <br />Deleting a eall <br /> <br />35 <br /> <br />The function ApplyNewCall () attempts to set the specified call. Several criteria <br />must be met in order to set the new call: <br /> <br />I. The user setting the call must have write permission to the district where the <br />diversion structure is located. <br /> <br />2. The specified set date must be in the format mmldd/yyyy hh:mm. <br /> <br />3. The current governing call at the structure must be junior to the new call being set <br />at that structure. <br /> <br />If any of the above criteria fail, the new call is refused and the user is notified of the <br />reason. <br /> <br />After all the criteria are met, the new caU is inserted into the database with a call to <br />SQLlnsertNewCall (), and the call structure representation in the i~-memory <br />graph is updated with a call to SetTheNewCallSearch (). SetTheNew- <br />Call Search () is the function called by InitCurrentCalls () (see the <br />"Synchronizing with the database" section on page 15). The difference is that Ini t- <br />Curren tCalls ( ) rebuilds the call structure for the entire stream network. <br />SetTheNewCallSearch () rebuilds the call structure only upstream from the <br />specified diversion structure (where the new caB has been set). <br /> <br />SetTheNewCallSearch () will release any junior calls it finds upstream from <br />the new caB. TIlls is a necessary action in order to maintain the integrity of the call <br />structure. The process of releasing a calJ involves marking the call as released in the <br />database-a matter of updating the release_date of that row, and removing that <br />call from the in-memory call structure. The function Ups trearnOverwri te ( ) <br />accomplishes the latter by performing an in-order traversal of the stream network <br />upstream from the released call and resetting the governing call at all structures where <br />the governing call was the released calL <br /> <br />Releasing a call is a simple operation as far as the application is concerned. First, the <br />function ApplyReleaseCall () verifies that the user has write permission to the <br />district where the call is being released, and that the specified release date is in the <br />format mm/dd/yyyy hh:mm. Then, the governing call is obtained from the structure <br />downstream from the released call. This governing call is applied to the structure <br />where the call was released and propagated upstream with a call to Ups trearnOv- <br />erwri te ( ) . Finally, the call in the database is marked as released by updating the <br />release_date of the call. <br /> <br />Users of the UNIX application are provided a tool to delete calls that were entered <br />erroneously. Only those users which have basinwide write permissions are permitted <br />to delete calls. Note that calls are never actually deleted from the database, they are <br />simply marked as deleted, which excludes them from being displayed or considered <br />by the application. <br /> <br />Deleting a call is performed by a call to the function DeleteCallFromDa ta- <br />base (). <br /> <br />Exchange Management <br /> <br />Exchanges are not represented as rigorously as calls in SPWRMS. There is no repre- <br />sentation of exchanges in the in-memory graph of the stream network, for example. <br />