Laserfiche WebLink
<br />000074 <br /> <br />Calls <br /> <br />Synchronizing with <br />the database <br /> <br />15 <br /> <br />. next: The next in the linked list of lag/loss records. <br /> <br />Each of these members may be accessed from the in-memory graph to retrieve lag and <br />loss information about a particular reach. <br /> <br />Calls are an example of data that is most-frequently retrieved from the database rather <br />than from the network graph. There are two reasons for the application to be designed <br />this way. First, other users may change the call structure on the river by setting or <br />releasing a call. The database is the location of all up-to-date call information. so a <br />query directly to the database gets the most recent information available about the call <br />structure. Second, most requests for call information relate to some interval of time <br />rather than to the current call structure in place on the river. The relational database is <br />the only source of historical information of this kind. <br /> <br />Some information relating to calls is retrieved from the in-memory graph. Before <br />retrieving the information, the application verifies that its representarion of the call <br />structure is still accurate. If a new call has been set since the call structure was estab- <br />lished, the call structure is rebuilt based on the list of calls stored in the database. <br />Current call information is stored in the node_records in the in-memory graph. <br />This assures that the caIl structure in the in-memory graph is up-to-date. The process <br />of rebuilding the call structure is described in the next section. <br /> <br />Historical Governing Calls at a Diversion Structure, including information displayed <br />on the Water Information Sheet (a list of the governing calls during the day at the <br />diversion structure immediately downstream from the district), may be extracted <br />using the function GetGoverningCalls () . This function is described in the <br />"Retrieving a Water Information Sheet" section on page 33. This function returns a <br />list of governing calls, since over a period of time more than one call may govern the <br />activities at a structure. <br /> <br />The in-memory graph is synchronized with the database whenever the user requests <br />information about the call structure. This is done to ensure that changes in the call <br />structure by other users are incorporated into the in-memory representation. The <br />central database is the repository for all data on calls, so it must be accessed to get the <br />most up-ta-date information. <br /> <br />The application maintains a global variable, las t_upda te, which stores the date <br />and time that the call structure was last rebuilt. When the user requests to view infor- <br />mation about calls, the application checks for any calls in the database set or released <br />after that date and time. If any are found, the application recreates the call structure. <br /> <br />The operations which initiate this validation/synchronization sequence arc all associ- <br />ated with the Edit/Edit Calls dialog. When the user opens this dialog. sets or releases <br />a call, the check is performed and caBs are synchronized if it is determined this step is <br />necessary. <br /> <br />The function which synchronizes the calls is Ini tCurren tCalls ( ) . This is the <br />same function used to create the call structure during program initialization. The <br />application simply rebuilds its representation of the call structure whenever this action <br />is determined to be necessary. Ini tCurrentCalls () resets the call portion of <br />the in-memory network and reads all the currently valid (not yet released) calls from <br />tbe database. For each call retrieved, the structure is located at the point at which the <br />call was placed, using the function Loca teStreamNetworkNodeBy- <br />StructureID ( ) . Then, an upstream search is initiated with the function <br />