Download software maintenance manual - Cospas
Transcript
8 - 23
D2NOV05
C/S D.002 – Issue 1
November 2005
a. Corresponding ComfirmationRequired from MidInfoCfg (record where mid
matches the beacon country code) is “Yes”.
b. ConfirmationStatus field is not NULL, “SENT” or “UDEL”
c. SpecialStatus is NULL (i.e., Normal status)
d. Record must have an “valid” email address field (not NULL or empty)
The actual query used within the software at time of installation reads as follows:
select bcnId15, OwnerName, a.BeaconRegType, BeaconRegName, EmailAddress
from RegistrationDB406 a, MidInfoCfg b, BeaconRegTypeCfg c
where a.BeaconRegType = c.BeaconRegType
and a.BeaconCountryCode = b.mid
and b.ConfirmationRequired = 'Y'
and (ConfirmationStatus IS NULL or ConfirmationStatus not in ('SENT', 'UDEL'))
and a.SpecialStatus IS NULL
and datediff(DAY, GETDATE(), dateadd(YEAR, 2, ConfirmPrintDate)) <=
(select SystemCfgValue from SystemCfg where SystemCfgName = 'CONFIRMATION REQUEST TIME')
order by bcnid15
If desired, the above query could be manually run at anytime from “SQL Query Analyzer” to
determine which records should be picked up in the next run. It is useful to note that the
IBRD implementation does not include records where ConfirmationStatus is NULL, as was
the case with the original RGDB code upon which the RGDB is based. In fact all new
records are assigned a default status of “CHGE” and hence a ConfirmationStatus of NULL
should not really occur.
Furthermore, no matter when an update is made to a record (other than by this “request
generation” process itself) the IBRD always sets the ConfirmationStatus to “CHGE” as well
as setting the ConfirmPrintDate to the current date and time. The status of “CFRM” is
reserved exclusively for when a user explicitly performs an online acknowledgement. As
such, the whole business of generating “requests for confirmation” really hinges almost
exclusively on the ConfirmPrintDate.
Finally, it is perhaps useful to note that there is no attempt here to maintain a two-year
renewal cycle that expires on any given day of the year like other types of registrations (e.g.,
car, vessel etc.) are often implemented. A “request for confirmation” is only generated when
a user has not made any update for a period of two years (minus the specified period in
SystemCfg to be precise) and any update at all will start the two year cycle over beginning at
the new date.
8.13 FileArcPurge Process
A special purpose application is used to purge files created by the IBRD software. This
application, named IBRDFileArcPurge.exe, runs as a scheduled task and uses a configuration
table in the IBRD database which indicates the folders to be checked and the “age out”
criteria of files to be purged.
The program is written in Visual Basic (Version 6.0), and is really a very simple set of code
that employs Microsoft supplied mechanisms (class named FileSystemObject) to perform the
necessary file management actions. The folders (or file paths) and the number of days to