JPH0447428A - File updating device - Google Patents

Abstract

PURPOSE:To automatically execute the restoration processing at a high speed by holding a record state before updating at the time of updating a file, and restoring releasing the file by discriminating the record state, in the case an error is generated. CONSTITUTION:At the time of updating a file by an updating record, a record before updating is saved in a backup memory 22, and thereafter, in accordance with the updating kind instructed by a record unit, the file is updated. At the time of updating this file, a state of each updating record is detected by referring to an updating state table 13 and a record state table 14, and held in an updating state management memory 21. In such a state, when an error is generated at the time of updating the file, a restoration processing of the file is executed, based on a record state stored in the memory 21. In such a way even if an error is generated at the time of updating the record on the file, the restoration processing can be executed automatically and at a high speed.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a file update device that has a function of restoring a file when an error occurs while updating a record on a file in an office computer or the like.

[Summary of the Invention] When updating a file, the file updating device of the present invention maintains the record status of the file before the update on a record-by-record basis, and when restoring the file, determines each of the above record status and immediately restores the file. This is how it was done.

[Prior Art] When updating a file that has already been created, a conventional file update device in an office computer, etc. locks the entire file to prevent the data from being rewritten by other processes, and updates the file on a file-by-file basis. If all record information is updated and an error (inconsistency) occurs, save the record with the error as an NG record in a separate file, and then print the saved NG record when all updates are completed. etc., output it to
After that, the user is responsible for repairing the adhesive. If a file is important and the user wants to restore it reliably, the user backs up each file before updating the file, and then restores the backup data if an error occurs.

[Problems to be Solved by the Invention] When an error occurs due to a file update as described above, the conventional file update device simply outputs an NG record to notify the user after the update is completed, and the subsequent processing is left to the user. However, there are problems in that the file recovery operation is extremely troublesome and takes a long time.

The reason for this is that when updating a file, the user must back up the file in advance, and when an error occurs, error recovery is performed in units of files with large data volumes. it is conceivable that.

When updating a file, the record status before the update is maintained for each record, and if an error occurs, the user can automatically recover the file by determining the record status above. It is clear that files can be quickly recovered without performing any recovery operations.

An object of the present invention is to automatically perform recovery processing when an error occurs while updating a record on a file.
Another object of the present invention is to provide a file update device that can be executed at high speed.

[Means to solve the problem] The means of the present invention are as follows.

(1) A file update means that, when updating a file using an update record, separately saves the record before update and then updates the file according to the update type specified for each record.

For example, the CPU 1 operates according to the type of update of the update record read out from the backup memory 22 and the update record file 16, which stores records before update.

(2) When updating the above file, for each updated record, check whether the record exists in the file before the update and should be deleted from the file, or whether the record exists in the file before the update and has been rewritten. A state retention means that maintains either of the following states: or whether the record did not exist in the file before the update and was added.

For example, an update status register 17 that holds the status by referring to the update status table 13 and the record status table 14;
This is the record status register 18.

(3) When restoring a file, determine the state of each updated record, and if it is in an added state, delete that record to cancel the added state, and if it is in a rewritten state, delete the updates that were retained at the time of update. A state canceling means that rewrites the previous record to cancel the rewritten state, and if it is a deleted state, cancels the deleted state.

For example, the CPU 1 operates by determining the status of each record stored in the update status management memory 21.

[Effect] The operation of the means of the invention is as follows.

When updating a file using an update record, the record before the update is saved in the backup memory, and then the file is updated according to the update type specified for each record. When this file is updated, the status of each updated record is detected by referring to the update status table and the record status table, and is held in the update status management memory.

If an error occurs during a file update, file recovery processing is performed based on the record status stored in the update status management memory.

[Example] An example will be described below with reference to FIGS. 1 to 8.

FIG. 1 is a block diagram showing the overall configuration.

In the figure, reference numeral 11 indicates a CP that controls the entire circuit.
U, this CPU 1 is connected to an update state table 13, a record state table 14, an update record register 15, and an update record file 16 via a pass line 12.
, update status register 17, record status register 18,
An update buffer 19, a work memory 20, an update state management memory 21, an ivy-up memory 22, and a source file 23 are connected.

In the update state table 13, update state tables I and 2 shown in FIGS. 2(a) and 2(b) are set.

The update status table in Figure 2(a) shows the management status when the first process is executed on the same record in the same file, and depending on the update type and the presence or absence of a record on the file, it shows the management status of "delete", "delete", " The following states are set: ``additional'', ``revised'', ``collection'', and ``error''. In each of these states, ``delete'': means deletion, leaving a state with no record; ``add'': means addition, creating a new record; Modify the field contents to the field value, "Collection": Indicates that the field value of the target record is added in the aggregation.

In addition, the update types include ■"Delete", ■"Add", ■"
There are six types: ``Addition/Correction'', ■``Addition/Tally'', ■U Correction'', and ■``Tally''.

The above update types are used as follows when creating an update record.

Add: If there is no record with the corresponding key in the file, you want to add it, but if there is, there is no need to update it.

Correction, deletion, aggregation: If there is a record with the relevant key in the file, you want to update it (correction, deletion, aggregation), but if there is no record, there is no need to update it.

Addition/Correction, Addition/Aggregation: When it is necessary to update the record of the corresponding key.

In the update status table I, for example, if the current update type is "delete", the update status is recognized as "delete" if there is a record on the file, and as "error" if there is no record.

The update state table (2) shown in FIG. 2(b) shows the relationship between the update type and the previous update state. When updating the same record for the second time or later, the record status is recognized based on the previous record status and the current update type, and the update status table (2) is used at this time. Please note that the update type this time is "Delete" and the previous record status is "Add".
, r-revised", "collection", and the current update type is "addition", and the previous record status was "revised", "collection". ” ■ “Add/Correct” ■ “Add/Tally” ■ “Correction” ■ “Tally” Sort in ascending order, so it is logically impossible, so the status is not set. .

In the update status table ■ above, if the current high-new species is, for example, "correction", and the previous update status is "deleted", then "
"Error" Otherwise, the update status is recognized as "Correction".

In addition, the record status table 14 includes FIG. 3(a),
Record status table I shown in (b).

■ is set.

Record status table I in Figure 3(a) shows the record status when the first process is executed for the same record in the same file, and it shows the record status depending on the six types of updates mentioned above and the presence or absence of records on the file. rDELJ rError, rRWTJ, rAPDJ status is determined. In each of these states, DEL: Deletion of a record on a file, Error: Occurrence of a logical contradiction, RWT: Rewriting of a record on a file, APD: Addition of a record to a file.

The record status table (2) shown in FIG. 3(b) shows the relationship between the update type and the previous record status.

When updating the same record for the second time or later,
The record status is recognized based on the previous record status and the current update type, and the record status table ■ is used at this time.

Note that if the current update type is "delete", it is logically impossible for the previous record status to be rAPDJ, rRWTJ, since it is assumed that the records are sorted by update type as described above. , no state setting is performed.

As shown in FIG. 4, the update status management memory 21 contains a file identifier 21a, a length 21b of the target record, and a number of keywords 21c of the target record.

Record number 21d of target record, update status 21e,
The record status 21f is set for the number of records to be updated. The above file identifier 21a is the oven identifier of the file to be updated, and the length 21b of the target record.
indicates the length of the backed up record to be updated, the number of keywords in the record to be updated 21c indicates the number of keywords in the record to be updated, and the record number 21d of the record to be updated is the physical record number of the record to be updated.

Further, the update status 21e indicates the status of "deletion", "addition", "correction", and "totalization" in FIG. 2, and the record status 21f indicates the status mode of the update record in FIG. 3.

As shown in FIG. 5, the update record file 16 stores update records consisting of "file name", "update type", "keyword K", and "data word A" to "data word G". .

Also, in the source file 23, as shown in FIG.
A source record consisting of "keyword K" and "data word A" to "data word G" is stored.

Next, the operation of the above embodiment will be explained.

Update records created in advance are stored in an update record file 16. Then, the source file 23 is updated using the update record stored in the update record file 16.

The processing operation of this file update will be explained below according to the flowchart of FIG. This flowchart is
Executed under the control of the UII.

First, update records stored in the update record file 16 are classified by key classification, that is, ■ "Delete", ■
"Add", ■ "Addition/Correction", ■ "Addition/Aggregation", ■ "
Sort in ascending order of "Correction" and ■"Tally" (Step Al
). The above sorting process is performed using the work memory 20.

After this sorting is completed, the update record is read from the update record file 16 into the update record register 15 (step A2), and it is determined whether the corresponding record exists in the source file 23 (step A3). Then, based on the presence or absence of records in this file and the current update type, Table I of the update status table 13 and record status table 14 (Fig. 2 (a), Fig. 3 (
Read the current update status and record status from step A4) and determine whether there is an error (see step A4).
Step A5). In this case, in both the update status table 13 and the record status table 14, if the update type is "Add", there is a record, and if the update type is "Delete", "Correction", or "Aggregation", there is no record. status is an error.

If it is determined that there is an error in step A5, the error processing in step A6, which will be described in detail later, is executed, and if there is no error, the update status is stored in the update status register 17 and the record status is stored in the record status register 18 ( Step A7). Then, the update record register 15
Update records held in the update status register 17
The update state management record shown in FIG. 4 is created from the data held in the record state register 18 and stored in the update state ring memory 21 (step A8).

Furthermore, it is determined whether the record status held in the record status register 18 is "RWT (rewrite)", "rAPD (addition)", or "rDEL (deletion)" (step A9); if rRWTJ; Step Al01r
If it is APDJ, the process proceeds to step A14, and if it is rDELJ, the process proceeds to step A18.

When the record status in the record status register 18 is rRWTJ and the process proceeds to step AIO, the corresponding record of the update target file in the source file 23 is locked so that it cannot be accessed from the outside. Next, the corresponding record is written to the backup memory 22 and backed up (step A11). After that, the above corresponding record is transferred from the source file 23 to the update buffer 1.
9 and corrected using the update record held in the update record register 15 (step A12.
A13).

When the record status in the record status register 18 is rAPDJ and the process advances to step A14, the target file in the source file 23 is updated and the corresponding record is clicked (step A15). Next, the corresponding record is written to the knob memory 22, and the corresponding record is transferred to the update controller 19 (step ALE).
, A17).

When the record status in the record status register 18 is rDELJ and the process advances to step A18, the corresponding record of the target file in the source file 23 is locked. Next, back up the above records to memory 2.
2 and upload it, and then transfer the corresponding record to update and sofa 19 (step
Tubu A20. A21).

When the processes of steps A13, A17, and A20 are completed, the process proceeds to step A21, where the next update record is read from the update record file 16 to the update record register 15, and it is determined whether the key is the same as the previous one. (Ste Tsubu A22).

If the key is the same as the previous one, the table ■(
(See FIGS. 2(b) and 3(b)), the current update status and record status are read out, and it is checked whether there is an error or not. In this case, in the update status table 13, the previous update status is "delete" and the current update type is "delete".
An error occurs when "correction" or "aggregation" is specified, or when the previous update status is "addition" and the current update type is "addition". In addition, in the record status table 14, when the previous update status is rDELJ and the current update type is "delete", "correction", or "summarization", the previous update status is APDJ and the current update type is " When "Add" is specified, the previous update status is rRWTJ and "Add" is specified as the current update type, an error occurs.

If it is determined that there is an error in step A24, error processing (step AS) is executed, and if there is no error, the update state read from table 2 of the update state table 13 is stored in the update state register 17 and recorded in the record state table 14. The record status read from table 2 is stored in the record status register 18 (step A25). Next, the contents of the update buffer 19 are updated based on the current update record and update status (step A26). Further, the update state management record shown in FIG. 4 is created from the update record held in the update record register 15, the data held in the update status register 17, and the record status register 18, and is stored in the update status management memory 21. (Step A27).

Thereafter, the process proceeds to step A21, where the next update record is read from the update record file 16 to the update record register 15, and it is determined whether the key is the same as the previous one (step A22). If the key is the same as the previous one, the processes of steps A23 to A27 are repeated, but if the key is not the same, it is further checked whether there is a next record in the update record file 16 (step A
28).

If there is a next record in the update record file] 86, the current record status is rAPDJ, "RWT", or "DEL" from the contents of the record status register 18.
(Step A29).

When the record status is rAPDJ, the update status register 17 further indicates the current update status as "addition", "correction",
Step A30) to determine which one is “aggregation”;
If “correction” or “aggregation”, update buffer 19
writes the contents held in the source file 23 (step 831) and locks the corresponding record (step A32). Also, when it is determined in step A29 that the current record status is "RWTJ", the processes in steps A3L and A32 are executed.

Then, when the process of step A32 is finished, if the current update status is determined to be "addition" in step A30, the current record status is changed to "addition" in step A29.
If it is determined that it is DELJ, the process returns to step A3 and the above-described process is repeated according to the update record held in the update record register 15.

Through the above processing, all update records held in the update record file 16 are read out, and step A
2g, if it is determined that the next record is not stored in the update record file 16, step A3
Proceed to step 3 to read the first record from the update state management memory 21 to the work memory 20, and set the record state to rDE.
It is determined whether it is LJ, rAPDJ, or "RWT" (step A34).

If the record status is "DEL", the corresponding record is deleted from the source file 23. If the process of step A35 is completed, or if it is determined in step A34 that the record status is rADDJ or rRWTJ, the process advances to step A3B, and whether reading of all records from the update status management memory 21 is completed or not. If it has not been completed, the next record is read from the update state management memory 21 to the work memory 20 (step A37), and then the process returns to step A34 and the same process is repeated. When all the processing for the records stored in the update state management memory 21 is completed, step A38 is sent from step A36 to step A38.
The process proceeds to step 100, where all records in the source file 23 are unlocked, and the file update process is ended.

Next, details of the error processing in step A6 will be explained according to the flowchart of FIG.

In this error processing, first, the first record is read from the update state management memory 21 to the work memory 2° (step Bl).The record states are rRWTJ, rAPDJ, r
Step B2), r
If it is RWTJ, the process proceeds to step B3, if it is "APD", the process proceeds to step B6, and if rDELJ, the process proceeds to step B8.

If the record status is rRWTJ and the process advances to step B3, the record of the corresponding key before the update is read from the backup memory 22, the corresponding record of the source file 23 is rewritten to the state before the update (step B4), and the corresponding record is locked. unlock.

If the record status is rAPDJ and the process advances to step B6, the key of the corresponding record is read from the backup memory 22, and the record with the corresponding key is deleted from the source file 23 (step B7).

If the record status is rDELJ and the process advances to step B8, the key of the corresponding record is read from the backup memory 22, and the record with the corresponding key in the source file 23 is unlocked (step B7).

When the processing of tX in steps B5, B7, and B9 is completed, it is determined whether or not all record reading from the update state management memory 21 has been completed (step BIO). If only record reading has been completed, the update status is The next record is read from the management memory 21 to the work memory 20 (step B11), and then the process returns to step B2 to determine the record status and execute the above-described process according to the determination result.

When all the processes for the records stored in the update status management memory 21 are completed, the status is determined in step BIO and the error process is terminated.

[Effects of the Invention] As detailed above, according to the present invention, when a file is updated, the record state before update is held for each record,
If an error occurs, the file is automatically restored by determining the status of each record listed above, so even if an error occurs, the user does not have to perform any recovery operations, and the recovery process is automatically performed. , and can be executed at high speed.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing the circuit configuration of a file updating device according to an embodiment of the present invention, and FIG. 2(a) is a block diagram showing the circuit configuration of a file updating device according to an embodiment of the present invention. (b) is a diagram showing the settings of the update status table, FIGS. 3(a) and (b) are diagrams showing the settings of the record status table, and FIG. 4 is a diagram showing the storage configuration of the update status management memory. Fig. 5 is a diagram showing the record format of the update [nocode file], Fig. 6 is a diagram showing the record format of the source file, and Fig. 7 is a flowchart showing the file update process.
FIG. 8 is a flowchart showing error processing. 11...CPU, 12...Pass line, 13...
Update status table, 14... Record status table,
15... Update record register, 16... Update record file, 17... Update status register, 18
... Record status register, 19... Update buffer, 20... Work memory, 21... Update status management memory, 22... Backup memory, 23... Source file.

Claims (1)

[Scope of Claims] A file update means that separately saves the record before update when updating a file using an update record, and updates the file according to an update type specified for each record; For each updated record, check whether the record exists in the file before the update and should be deleted from the file, or whether the record exists in the file before the update and has been rewritten. A state retention means that maintains either the state of whether the record does not exist in the file or has been added, and when the file is restored, determines the state of each updated record, and if it is in the added state, deletes the record. If the record is in a rewrite state, it is rewritten to the pre-update record that was retained at the time of update and the rewrite state is canceled. If it is in a delete state, the deletion state is canceled. A file update device comprising: a state release means.