THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700


S U M M A R Y


DIARY: December 8, 1997 00:33 AM Monday; Rod Welch

Develop "update" feature in 06116 SDS data base for HTML.

1...Summary/Objective
2...06116 - Planning Code for Updating HTML Data Base of SDS Records
3...Correct Thinking Appears to be Incorrect
4...Saving Diagnostics in SDS Record Destroys Actual Time of Record
5...Opening Each File to Evaluate it Takes 1 - 3 hours for Update?
6...Prospects of modifying Ffind.exe to use Date Param
7...Algorithm to Get List of Records Based on Subject to Update
8...06116 - Code Update Data Base


..............
Click here to comment!

CONTACTS 

SUBJECTS
Intranet, HTML Code
SDS Tools, SDS Data Base
Right Looks Wrong

0805 -    ..
0806 - Summary/Objective
0807 -
080701 - Follow up ref SDS 4 3900, ref SDS 2 5194.
080702 -
080703 - Added ability to update the HTML SDS data base, per the objective on
080704 - on 971206. ref SDS 5 3454   This requires getting a list of SDS
080705 - records for a specified subject and then determining which have
080706 - changed (been saved) since the time of the HTML record creation or the
080707 - last update.
080708 -
080709 -     An overview of system is explained on 971208. ref SDS 5 6000,
080710 -
080711 -     [Improved system on 980311. ref SDS 7 5043
080712 -
080713 - This took two days, including testing and refinements, but I recorded
080714 - everything here.
080715 -
080716 - Was able to accomplish this additional capability using the existing
080717 - 06116 processor called from within the Subject Index main menu.
080718 -
080719 - Initial planning and analysis was erorneous. ref SDS 0 1319
080720 -
080721 -
080722 -
0808 -
0809 -
0810 - Progress
0811 -
081101 -  ..
081102 - 06116 - Planning Code for Updating HTML Data Base of SDS Records
081103 -
081104 - Follow up ref SDS 2 5350, ref SDS 1 1914.
081105 - ..
081106 - Considered adding code to try Morris' idea per telecon on
081107 - 971204, ref SDS 3 2033, to use "dir" to compare the SDS record with
081108 - the HTML file, in determining whether to update an HTML formatted SDS
081109 - record.
081110 -
081111 - Make F1 the action key. ref OF 1 3319, will assign it to mouse pos
081112 - later.
081113 -
081114 -     This method was ultimately applied below. ref SDS 0 1326  However,
081115 -     the following analysis developed a perception that this method was
081116 -     incorrect.  I leave it to illustrate how the correct path can
081117 -     sometimes appear wrong; but, if we have enough time to continue
081118 -     thinking about it the correct path can be discovered.
081119 -
081120 -
081121 - Correct Thinking Appears to be Incorrect
081122 -
081123 - Turns out that using dir on both the HTML and the DOS files is an
081124 - invalid test because the HTML data base is always created later than
081125 - the original file, by definition, so merely comparing dir dates is
081126 - inadequate.
081127 -
081128 - We need to determine merely whether the current SDS record has been
081129 - changed since the last time it was converted to HTML.  Basically this
081130 - can be addressed by whether the file has been saved since the last
081131 - conversion to HTML.
081132 -
081133 - We could look at the size of the files, except the HTML conversion
081134 - process changes this.
081135 -
081136 - On the other hand, we could save the size and/or date/time of the
081137 - current file in the record each time it is converted to HTML and then
081138 - compare the current size based on actual dir with the value in the
081139 - file from the last HTML update.
081140 -
081141 -     The above three (3) para are incorrect.  The following continued
081142 -     analysis led to the correct solution.
081143 -
081144 -
081145 -  ..
081146 - Saving Diagnostics in SDS Record Destroys Actual Time of Record
081147 -
081148 - This requires a dos /c call for each file and it requires changing the
081149 - date and time of the file each pass, so we never know when the last
081150 - time work was performed on the record.  That is not a good system.
081151 -
081152 -
081153 -  ..
081154 - Opening Each File to Evaluate it Takes 1 - 3 hours for Update?
081155 -
081156 - It requires reading in every potential file, which would greatly
081157 - reduce the speed of each update.  If we are updating say 2 or 3 files,
081158 - then it could take an hour if it takes .4 seconds to process every
081159 - file, which now is at 30K files.  This requires about 3 hours for the
081160 - update.  If it takes only .2 seconds to open the file, evaluate it,
081161 - close it and get the next one, that is still 90 minutes, which is
081162 - impractical.
081163 -
081164 - If we do this, Seems like it would work better not to use stufq as a
081165 - temporary file, and instead use the original file, so when the
081166 - diagonstics are posted, we just say "save" and go on.
081167 -
081168 -
081169 -  ..
081170 - Prospects of modifying Ffind.exe to use Date Param
081171 -
081172 - Actually, we need to look at every file in the data base and grab up
081173 - all of them that have been changed since the last update.
081174 -
081175 - This requires something like an sf or ffind command that will work
081176 - with a date param, so it will only list files since a particular date,
081177 - similar to pkzip.
081178 - ..
081179 - I prepared a letter to Morris requesting he consider creating
081180 - this feature, but further analysis below resulted in solving the
081181 - problem without this added feature to ffind.exe.  So I did not send
081182 - the letter.
081183 -
081184 -     Wound up deleting the letter, because the original solution
081185 -     suggested by Morris turned out to work.
081186 -
081187 -     [On 980325 had similar experience trying to revise 06116 so it
081188 -     will run continuously after revising 070405. ref SDS 8 0911]
081189 -
081190 -
081191 -  ..
081192 - Algorithm to Get List of Records Based on Subject to Update
081193 -
081194 - We could then sort the 06116 1y output file that has the list of
081195 - record IDs for the target subject, with the sf list of files that have
081196 - been updated, then delete any lines that are not in both lists, plus
081197 - the duplicates, and we would then have a list of files that need to be
081198 - updated.
081199 -
081200 -     This method was unnecessary and was not applied in the solution
081201 -     developed next.
081202 -
081203 -
0813 -

SUBJECTS
Intranet, HTML Code
SDS Tools, SDS Data Base
Right Looks Wrong

1206 -
120601 - 06116 - Code Update Data Base
120602 -
120603 - Was able to add some code that uses the "dir" command per Morris'
120604 - suggestion, cited above. ref SDS 0 1146  Simply integrated the code
120605 - for the new steps of updating by using existing code, since it is
120606 - similar.
120607 - ..
120608 - Line 160 -label updt, ref OF 1 1679, this is where F1 will start
120609 - operation, merely by setting a flag that an update is underway.
120610 -
120611 - Line 320 -label comDt, ref OF 1 2904, added code to compare dir of
120612 - HTML and SDS record.
120613 -
120614 - ..
120615 - Line 670 -label getrcd, ref OF 1 5904, about 30 lines below,
120616 - this is where 070405 is called to create the HTML conversion.
120617 -
120618 - ..
120619 - Revise collapse field, macro 79 so it does not use cut file.
120620 -
120621 -     [.... did this later today in another record. ref SDS 6 2402,]
120622 -
120623 - Line 1010 -label sepLN, ref OF 1 3776, decided to omit the code that
120624 - puts the separator line between the Exec Summary, and the record,
120625 - since it is redundant now.
120626 -
120627 -
120628 -
120629 -
120630 -
120631 -
120632 -
120633 -