JPH0447427A - File updating device - Google Patents

Abstract

PURPOSE:To efficiently execute the file updating processing by executing the updating by whether the designated updating kind and the record concerned exist or not at first, and by the designated updating kind and the previous updating state in a second time or thereafter, and rewriting a file in the end of the processing. CONSTITUTION:In the case there are plural updating records of the same key, at the time of first updating, tables I in an updating state table 13 and a record sate table 14 are referred to, and in accordance with whether the record concerned exists or not, an updating state is determined, and held in a register 17. Subsequently, the record concerned read out of a file 23 is expanded onto work memory 20, and in accordance with the determined updating state, the updating processing is executed on the work memory 20. At the time of updating in second time or thereafter, tables II in the table 13 and the table 14 are referred to, and in accordance with the previous updating state held in the register, the record concerned is subjected to updating processing on the work memory 20. Next, when the updating records of the same key are all processed, a file 16 is updated by the record updated on the memory 20. By suppressing the number of times of a file access to the minimum, the file updating processing is executed efficiently.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a file update device in an office computer or the like that has a function of updating records on a file in real time.

[Summary of the Invention] When updating the same key record multiple times, the file update device of the present invention initially determines the current update state based on the update type specified by the update record and the presence or absence of the corresponding record. However, from the second time onwards, the current update state is determined based on the update type specified by the update record and the previous update state, and the update process is performed on the work memory.
The file is rewritten at the end of processing for the same key record.

[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 locks the entire file in file units. In this case, if there are multiple update records for the same record, the record information will be written/written to the source file each time the record update process is performed.
I am trying to read it.

For example, as shown in FIG. 8, for record f stored in source file 1, three update records 2A,
If there are 2B and 2C, first, the record f is read to the memory 3a. Then, the record f read into the memory 3a is updated (4a) based on the first two update records. For example, the "quantity" A of the update record 2A is added to the specific field "quantity" of the record f, and the addition result rf+AJ is written to the source file 1.

Next, record f updated from the above source file 1
(f1A) is read out to the memory 3b, and updated (4b) is performed based on the next update record 2B. For example, record 2 for updating a specific field “amount” of record f.
“Amount” B of B is added, and the addition result is rf+A+B
J is written to source file 1.

Next, record f (
f+A+B) is read out from the memory 3cJ and updated (4c) based on the next update record 2C. For example, "reservation" C of update record 2c is subtracted from a specific field "inventory" of record f, and the subtraction result rf+
A+B-CJ is written to source file 1.

[Problems to be Solved by the Invention] The conventional file update device described above, when there are multiple update records for the same record, updates the file each time the file is updated based on each update record. Reading/writing processing must be performed, resulting in a problem in that the number of accesses to the file increases and processing efficiency decreases.

The reason for this is that when multiple update processes are performed on the same record, the update status is not memorized during the process, and therefore the processing results are written to a file each time one update process is completed. It is thought that it is necessary to memorize it in detail.

Therefore, when performing multiple update processing on the same record, at the first update, the current update status is determined based on the specified update type and the presence or absence of the corresponding record, and the current update status is stored and updated in the work memory. From the second time onward, the update status is determined based on the specified update type and the previous update status, and the update process is performed on the work memory, and the file is rewritten in the last process for the same record.
It is clear that the number of file accesses can be reduced.

An object of the present invention is to provide a file update device that can minimize the number of file accesses and efficiently perform file update processing when multiple update processing is performed on the same record.

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

If there are multiple update records with the same key, at the first update, the update status is determined according to the update type specified by the update record and the presence or absence of the corresponding record in the file, and the corresponding record is stored in the work memory. first updating means for expanding and updating on the work memory according to the determined update state;

For example, the CPU II refers to Table I in the update status table 13 and record status table 14 and performs update processing on the update buffer 19.

For the second and subsequent updates, the current update status is determined according to the update type specified by the update record and the previous update status, and the corresponding record in the work memory is updated according to the determined update status. A second updating means for updating.

For example, the CPU 1 refers to table (2) in the update status table 13 and record status table 14 and performs update processing on the update buffer 19.

File updating means for updating the file with the updated record on the work memory when the updating record of the same key is processed by the second updating means.

For example, the CPU 1 rewrites the source file 23 based on the contents of the update buffer 19.

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

If there are multiple update records with the same key, at the first update, refer to the update status table and the table ■ in the record status table, and check the update type specified by the update record and the presence or absence of the corresponding record in the file. The update state is determined accordingly and held in the register. Then, the corresponding record read from the file is developed on the work memory and updated on the work memory according to the update state determined above.

For the second and subsequent updates, refer to the update status table and the table ■ in the record status table, and update the current update status according to the update type specified by the update record and the previous update status held in the register above. Determine the update status,
Hold in register.

The corresponding record is updated on the work memory according to the update state held in this register.

Then, when all update records with the same key are processed in the second and subsequent updates, the file is updated with the updated records on the work memory, and the update process ends.

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

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 11 is provided with an update state table 13, a record state table 14, an update record register 15, an update record file 16,
Update status register 17, record status register 18, update buffer 19, work memory 20, update status management memory 21, backup memory 22, source file 2
3 is connected.

In the update state table 13, update state tables ① and ② 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 for the same record in the same file, and it shows the management status when the first process is executed for the same record in the same file. ", r-revised", "collection", "error"
state is set. In each of these states, ``delete'' means deletion, leaving a record without a record, ``addition'' means addition, creating a new record, and ``revision'' means correction, which means changing the target 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'', ``Correction'', and ■ ``Tally''.

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

Add: If there is no record with the relevant 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 is r-revised", r-collection J. ” ■ “Add/Correct” ■ “Add/Tally” ■ “Correction” ■ “Tally” Sort in ascending order, so it is logically impossible, so the status is not set. .

In the above update status table ■, if the current update type is, for example, "correction", and the previous update status is "remove", then "
If not, the update status is recognized as "Error", otherwise it 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, "Error",
rRWTJ, rAPDJ states are determined. In each of these states, DEL: Deletion of a record on a file, Error m: Occurrence of 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 because 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, length of the target record 21b, number of keywords of the target record 21c, record number 21d of the target record, update status 21e, code status 21f, as many as the number of records to be updated. Set. The above file identifier 21a is the oven identifier of the file to be updated, the length of the target record 21b is the length of the backed up record to be updated, the number of keywords in the target record 21c is the number of keywords in the record to be updated, and the record number 21d of the target record is the update Indicates the physical record number of the target record.

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 an error is determined in step A5, the error processing in step A6 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 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 A8).

Furthermore, it is determined whether the record status held in the record status register 18 is rRWT (rewrite), rAPD (addition), or rDEL (deletion) (step A9); if rRWTJ, step Al0
If it is 1rAPDj, the process proceeds to step AL4, and if it is rDELJ, the process proceeds to step A1g.

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 proceeds to step A14, the target file in the source file 23 is updated and the corresponding record is locked (step A15). Next, the corresponding record is written to the backup memory 22 for backup, and the corresponding record is transferred to the update buffer 19 (step Ale, A17).

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

When the processes of steps AI3, 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. (Step A22).

If the key is the same as the previous one, the update status table 13 and record status table 14 are updated based on the current specified update type and the previous update status and record status held in the update status register 17 and record status register 18. From the table ■ (see Figures 2(b) and 3(b)),
The current update status and record status are read and checked to see if there is an error. In this case, in the update status table 13, when the previous update status is "Delete" and the current update type is "Delete", "Correction", or "Aggregation", and the previous update status is "Add". "Added" as this update type
An error occurs when specified. 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 "RWTJ".
An error occurs when "Add" is specified as the update type for this time.

If it is determined that there is an error in step A24, error processing (step A6) 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 it is the same key as last time, follow steps A23 to A27 above.
The above process is repeatedly executed, but if the keys are not the same, it is further checked whether the next record exists in the update record file 16 (step A28).

If the update record file 16 has the following code, the current record status is rAPDJ, rRWTJ, rDELJ from the storage 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
The content held in is written to the source file 23 (step A31), and the corresponding record is locked (step A32). Also, when it is determined in step A29 that the current record status is rRWTJ, the processing in steps A31SA32 is also executed.

When the process of step A32 is finished, if it is determined that the current update status is "addition" in step A30, the current record status is changed to r 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 the update records held in the update record file 16 are read, and step A
If it is determined in step A28 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 change the record state to "DE".
It is determined whether it is "L" or [A P DJ, rRWTJ (step A34).

If the record status is rDELJ, the corresponding record is deleted from the source file 23. If the process of step A35 is finished, or if it is determined in step A34 that the record status is rADDJ or rRWTJ, the process advances to step AH, and whether reading of all records from the update status management memory 21 is finished or not. Check if it is not completed, and if it is not completed, update status management memory 2
1 to the next record to the work memory 20 (step A37), and then returns to step A34 to repeat the same process. When all the processes for the records stored in the update state management memory 21 are completed, the process proceeds from step A36 to step A38, where all the records in the source file 23 are unlocked, and the file update process is ended.

Note that in the above embodiment, when updating the same key, additions are made to the file immediately upon update, and deletions are made at once after all records have been updated.
Similarly to correction, aggregation, etc., records may be added or deleted at the end of updating for the same key.

[Effects of the Invention] As described in detail above, according to the present invention, when updating the same key record multiple times, the specified update type is first updated based on the specified update type and the presence or absence of the corresponding record, and from the second time onwards, the specified update type is updated. The current update status is determined based on the previous update status and the update is performed on the work memory, and the file is rewritten at the end of processing for the same key record, so the number of accesses to the file is minimized. File update processing can be performed efficiently.

[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 record file, Fig. 6 is a diagram showing the record format of the source file, Fig. 7 is a flowchart showing the file update process, and Fig. 8 is the same as the conventional file update device. FIG. 3 is a diagram illustrating processing operations when updating a key record multiple times. 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...Updating buffer, 20...Work memory, 21...Update status management memory, 22...Backup memory, 23...
source file.

Claims (1)

[Claims] When there are multiple update records with the same key, at the time of the first update, the update status is determined according to the update type specified by the update record and the presence or absence of the corresponding record in the file, a first update means for expanding a record on a work memory and updating the work memory according to the determined update state; a second update means that determines the current update state according to the previous update state and updates the corresponding record on the work memory according to the determined update state; 1. A file updating device comprising: file updating means for updating the file with the updated record on the work memory when the updating record is processed and disappears.