Archive/purge
This function is used to launch purging and archiving operations.
The SAFE X3 software is able to manage, by means of the archiving / purging functions, the transfer to archives or the purging of entries that no longer change, and are considered sufficiently old that they are not frequently consulted.
Only data considered as closed (i.e. that will not change any more) can be purged or archived.
The archiving is carried out by transfer of data from a folder table to a table with the same structure (with two additional fields, CREHISDAT and CREHISUSR, which is used to know the dates and operators that archived the data). This table is defined in a dedicated folder, which uses the current folder as a 'mother' folder, and whose creation is automatically carried out upon first archiving.
The interest in this method lies in the fact that the standard inquiry functions for the archived data operate by simple connection to this folder, in the same way that they operate for the current folder.
When connected to the archive file, it will only be possible to view the archived data separately, not simultaneously with non-archived data of the same type. However, if an archive table refers to common data (that willl not be archived by definition) or to data for which no archive table has been defined, the inquiry can zoom to the non-archived data.
The Purging rule setup is used to define the 'shelf life' from which the movements can be purged or archived, following coherence rules by table group defined elsewhere.
According to the concerned business module, the processing can also take into account the value of certain parameters. Their list is given in a separate document.
If the user wants to view specific movements, some of which are located in the live folder and others in the archive folder, union-type SQL queries will have to be defined in both tables concerned, via specific SQL queries or views, for example.
Prerequisites
It is necessary to have already created the archive folder associated with the current folder in order to manage the archiving and also to have defined the corresponding archiving/purging parameters .
Screen management
Entry screen
Presentation
On starting the function, a single screen is displayed that is used to define the information concerning the purging operation to be launched.
Once these parameters are entered, the validation of the screen causes the launch of the function. When this is finished, a log file will be displayed to give the result in a more or less detailed fashion.
Close
Fields
The following fields are present on this tab :
Block number 1
| Define the archiving/purging code to be launched. This makes it possible to restrict the operation to a single group of tables. If a general function is to be launched, the code should be left empty. |
Block number 2
| Define if the archiving process must be launched. |
| Define if the purging process must be launched. |
Block number 3
| Select this check box to include all companies. To run this process for a single company, leave clear. |
| Code of the company on which the processing is done. |
Block number 4
| If this check box is ticked, it causes the writing, of the operation log, of a list of each line purged or archived (as they occur, the main keys for the principal table in the purge group; the detail of the lines purged or archived in the linked tables is never given, however in this case the number is indicated). If this box is not checked, for each table, there will be a message giving the total number of lines purged or archived for the table. This box is also active in simulation mode, to identify the detail of what would have happened if the function had been launched in real mode. Warning, the use of this box can lead to the creation of a very large log file. |
| If this box is checked, the function creates a log (detailed or not) without actually carrying out the purging and/or archiving. |
Close
Notes
This operation can be extremely long. Therefore it makes sense to run it regularly in batch mode (the frequency parameters by table group make it possible to define what should be carried out for each purging/archiving run).