Laserfiche WebLink
<br />p,u 0 J 78 <br /> <br />Denver Checksheet <br />data management <br /> <br />23 <br /> <br />Data from the Denver Checksheet is all stored in the database table checksheet_data. <br />Each sheet holds a month's worth of data values and is referenced with a date corre- <br />sponding to the first day of the month. <br /> <br />Point Flow File Generation <br /> <br />Point flow file generation occurs from the Query point flow menu options (one for <br />each selectable reach). In each case a single cal1 to the function CreatePoint- <br />FlowFileSave () is made, which in turn calls the DMI function Crea te- <br />PointFlowFile () passing the appropriate water district and date (stan and end <br />dates from the preferences dialog). This function creates a temporary file containing <br />the point flow information. Finally the user is prompted for a name for this file, and <br />the file is renamed. <br /> <br />1.6 Data Management Interface <br /> <br />The data management interface, or DMI, is the application component that is respon- <br />sible for all interactions with the database and in-memory graph. DMI functions <br />perform all requests from and changes to the database tables. <br /> <br />Architecturally, there are several reasons for separating functions into a DMI rather <br />than embedding them in the GU!. DMIs allow all embedded SQL (Structured Query <br />Language) source code to be localized, so that changing the database engine does not <br />require massive recording effort. Also, it allows much of the source code to be <br />reused-<>ne function can be called by different parts of the GU!. Finally. it makes the <br />details of accessing the data invisible to the portions of the application that need the <br />information and provides a uniform access mechanism for all system data. For <br />example, accessing data from the UNIX GUI is done exactly the same as from the PC <br />application, which uses a very different technique to access the data. The PC applica- <br />tion uses communications routines to package data and send it over phone lines to the <br />server, but many of the functions that the PC ends up calling are exactly the same <br />functions called by the UNIX GU!. This would not be possible if the DMI functions <br />were pan of the GU!. <br /> <br />Some DMI source code files contain embedded SQL and are precompiled with a tool <br />provided by Informix. These source files all have an .ec suffix and are located in a <br />single directory, $SPLATfElsrc/dmi!. The remaining DMI routines are scattered <br />among the src directories and are linked to form a binary library used by several appli- <br />cations including UNIX GUI, spServer, and LoadOverlay file. <br /> <br />For the PC application, a separate DMI server runs on the UNIX workstation when a <br />user dials in. This is composed of the UNIX DMI code (all the Motif GUI code is <br />excluded from this server) plus a communications routine. See the "Client-Server <br />Implementation-Communications" section on page 35 for a description of this <br />system. <br /> <br />For the LoadOverlay file application, a parser to process the input is linked with the <br />DMI library to create the executable. <br /> <br />This section describes the basic functionality provided by the SPWRMS DM!. There <br />is a direct relationship between the GUI and the DMI, since every GUI operation <br />