Database update operation system

Abstract

To provide a database update operation system for preventing consistency with data before update from being lost when a plurality of tasks update the same data at the same timing.SOLUTION: The update operation system X is an update operation system for updating a DB12 (database). When a plurality of tasks update the same date at the same timing with respect to a task that performs an update operation of a DB12, the detection unit 10 detects that the DB12 is updated by the task that performs the update operation first. The update processing unit 11 updates the DB12 by reflecting, in the DB12, only the update content of the task for which the update operation has been performed first and which has been detected by the detection unit 10. As a result, the update content of the task that has performed the update operation first is reflected.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] In particular, the present invention relates to a database update operation system that accepts user operations to update a database. [Background technology]

[0002] As an example of a DB update operation system that updates a conventional database (hereinafter abbreviated as "DB"), Patent Document 1 discloses a sales support system that displays issue information about complex structured bonds on a customer's deposit details and transaction details, allowing sales representatives to understand the information and easily understand the terms of the structured bonds. In this sales support system, when an AP server receives a request from a terminal device to view the deposit details or transaction details corresponding to a customer code, it displays and outputs to the terminal device issue data of the structured bonds for the customer's deposited or traded issues in an anchor format that enables them to be identified as structured bonds, and when a request from the terminal device to view the setting condition data for the structured bond issue data is received, it displays and outputs to the terminal device the setting condition data corresponding to the structured bond issue data.

[0003] In a system where a database is updated by user operations, if multiple tasks update the same data at the same time, the task that performed the update first will lock the table due to the database's exclusive control. As a result, tasks that perform updates later will be forced to wait and will not be able to update. Then, after the update by the task that performed the update earlier has finished, the database will be updated with the input from the task that performed the update later. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-101607 Summary of the Invention [Problem to be solved by the invention]

[0005] In a conventional DB update operation system, once the DB update processing by the task that performed the earlier update operation is completed, the DB update processing by the task that performed the later update operation becomes possible. In this case, the DB update processing by the task that performed the later update operation is executed regardless of the contents of the DB update processing by the task that performed the earlier update operation. However, in a DB update operation system, data containing multiple items is updated at once in a form, etc., so there is a possibility that a column (item) updated in the DB update process by a task that performed an earlier update operation may be overwritten with a different value by a task that performed a later update operation, resulting in a loss of consistency with the data before the update.

[0006] The present invention has been made in view of the above circumstances, and aims to provide a DB update operation system that prevents data from becoming inconsistent with the data before the update, thereby resolving the above-mentioned problems. [Means for solving the problem]

[0007] The database update operation system of the present invention is a database update operation system that updates a database, and is characterized by comprising: a detection unit that detects, when multiple tasks update the same data at the same time as a task that updates the database, that the database has been updated by the task that performed the update operation first; and an update processing unit that updates the database by reflecting only the update contents of the task that performed the update operation first, which are detected by the detection unit, in the database. The database update operation system of the present invention is characterized in that the update processing unit does not update the database for a task that performed an update operation later, but notifies the task that performed the update operation first that the data was updated. The database update operation system of the present invention is characterized in that the database includes an update key representing the previous update information in addition to the primary key, the detection unit compares the update key acquired by the task when acquiring data for the update operation with the latest update key contained in the database, and if the comparison by the detection unit results in a match, the update processing unit determines that the task was the one that performed the first update operation and updates the database, but if there is a mismatch, the update processing unit determines that the task was the one that performed the update operation later and does not perform the update processing. The database update operation system of the present invention is characterized in that, if the update processing unit does not perform the update processing, it presents an alert to the effect that the update could not be performed, and presents information at the time of the update including the previous update information of the latest update key, the DB session ID, a timestamp, and the user ID of the person who updated it, or any combination thereof, thereby allowing the user to determine when and by whom the last update was made. [Effects of the Invention]

[0008] According to the present invention, when a task that updates a DB updates multiple tasks simultaneously, the present invention can provide a database update operation system that can prevent data from becoming inconsistent with the data before the update by detecting that the DB has been updated by the task that performed the update operation first and updating the DB by reflecting only the update contents of the task that performed the update operation first in the DB. [Brief explanation of the drawings]

[0009] [Figure 1] 1A is a system configuration diagram of a DB update operation system according to an embodiment of the present invention, and FIG. 1B is a conceptual diagram showing an example of an update key. [Figure 2] 10 is a flowchart showing the flow of DB update operation processing according to the embodiment of the present invention. [Figure 3] 3 is a conceptual diagram showing an example of updating a form and a DB in the DB update operation process shown in FIG. 2. FIG. [Figure 4] 3 is a screen example in the update-impossible presentation process shown in FIG. 2. [Figure 5] 1 is a conceptual diagram showing a form for a conventional DB update operation process and an example of DB update. DETAILED DESCRIPTION OF THE INVENTION

[0010] <Embodiment> Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The DB update operation system X according to this embodiment is an example of an update operation system that updates a database (hereinafter abbreviated as "DB"). In this embodiment, the DB update operation system X may be, for example, a CRM (Customer Relationship Management) system in which a company centrally manages relationships with customers as customer information in DB 12. Such a CRM system is used to promote sales activities by storing customer attribute information, customer contact information prepared as daily reports by customer service personnel, etc. in DB 12. However, the DB update operation system X according to this embodiment is not necessarily applicable only to this field, but can be applied to various systems that acquire application operations by users and process changes to DB12 based on the content of the operations.

[0011] More specifically, in this embodiment, the DB update operation system X acquires user operations in the AP server 2 according to the processing units (hereinafter referred to as "tasks") of the programs executed for each connection session connected from the terminal 3. Then, in the DB server 1, the system is configured as a DB update operation system that updates, for example, the sales support DB 12 based on the user operations. The configuration of this DB update operation system X will be described in detail below.

[0012] 1(a) shows the system configuration of a DB update operation system X according to this embodiment. The DB update operation system X is configured by connecting a DB server 1, an AP server 2, and one or more terminals 3 to a network 4.

[0013] The DB server 1 is an information processing device that stores and processes the DB 12. In this embodiment, the DB server 1 is, for example, a PC (Personal Computer) server, a DB server, a storage server, a NAS (Network Attached Storage), a dedicated machine, a general-purpose machine, or the like that includes the DB 12. In this embodiment, the DB server 1 stores company information, customer-related information, sales activity information, and the like.

[0014] In this embodiment, the DB server 1 includes a control unit, a storage unit, a network transmission / reception unit, and the like as a control configuration. Of these, the control unit is a control and calculation means composed of, for example, a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), NPU (Neural Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Processor), FPGA (Field Programmable Gate Array), etc. The storage unit is a non-transitory storage medium such as a RAM (Random Access Memory), a ROM (Read Only Memory), or an HDD (Hard Disk Drive). ROM also includes non-volatile devices such as flash memory. In this embodiment, the storage unit stores DB12, as will be described later. The network transceiver is a network interface for connecting to the network 4. In this embodiment, the network 4 may be the Internet, a mobile phone network, a dedicated line, or the like, connected using protocols such as TCP / IP or UDP.

[0015] The AP server 2 is an information processing device that provides applications (hereinafter abbreviated as "apps") such as CRM. In this embodiment, the AP server 2 is, for example, a PC server, a WWW (World Wide Web) server, an ASP server, a NAS, a dedicated machine, or a general-purpose machine. In this embodiment, the AP server 2 accesses the customer information in the DB server 1 and provides the customer information to the terminal 3, and transmits the sales activity information input from the terminal 3 to the DB server 1 for storage. The AP server 2 also provides the sales activity information to the terminal 3.

[0016] Like the DB server 1, the AP server 2 also includes a control unit, a storage unit, a network transmission / reception unit, and the like.

[0017] The terminal 3 is an information processing device that connects to the AP server 2 and executes an application. In this embodiment, the terminal 3 is, for example, a PC, a smartphone, a tablet terminal, a PDA (Personal Digital Assistant), a dedicated business terminal, or other terminal. In this embodiment, the terminal 3 uses a WWW web browser or application to access the AP server 2. The user of the terminal 3 can then obtain and update information on sales activities and the like using a GUI (Graphical User Interface). This updated sales activity information etc. is sent to the AP server 2.

[0018] Like the DB server 1 and AP server 2, the terminal 3 includes a control unit, a storage unit, and a network transmission / reception unit, and also includes an input unit 31, a display unit 32, and the like. Of these, the input unit 31 is a keyboard, a pointing device such as a mouse, a trackball, a touchpad or a touch panel, an infrared device, a camera, a biometric authentication device such as a fingerprint or vein authentication device, or other information input device. The display unit 32 is a display device such as an LCD (Liquid Crystal Display), an organic EL (Organic Electro Luminescence, Organic Light Emitting Diode) display, an LED (Light Emitting Diode), electronic paper, or a fluorescent display tube. The input unit 31 and the display unit 32 may be integrally formed as a touch panel display or the like.

[0019] Next, the functional configuration of the DB update operation system X according to this embodiment will be described. In this embodiment, the control unit of the DB server 1 of the DB update operation system X includes a detection unit 10 and an update processing unit 11. The storage unit of the DB server 1 stores a DB 12.

[0020] When a plurality of tasks update the same data at the same timing, the detection unit 10 detects that the DB 12 has been updated by the task that first performed the update operation, for the task that updates the DB 12.

[0021] The update processing unit 11 updates the DB 12 by reflecting only the update content of the task that performed the first update operation, which was detected by the detection unit 10, in the DB 12. More specifically, if the comparison by the detection unit 10 shows a match, the update processing unit 11 determines that it is the task that performed the update operation first and processes the update of DB12, but if there is no match, it may determine that it is the task that performed the update operation later and not process the update.

[0022] On the other hand, the update processing unit 11 may not update the DB 12 for the task that performed the update operation later, but may notify the task that performed the update operation first that the data has been updated. If the update processing unit 11 does not perform the update processing in this way, it sends an alert to the effect that the update could not be performed, and transmits information at the time of update including any or any combination of the previous update information of the latest update key, the session ID of DB12, a timestamp, and the user ID of the person who updated, to the AP server 2. In this way, the AP server 2 presents this information to the user via the app, allowing the user to determine when and who last updated the data.

[0023] The DB 12 may be, for example, a hierarchical DB, a network DB, a relational DB, etc. In this embodiment, an example will be described in which the DB 12 is a table-type relational DB that can be accessed using SQL language or the like through a DBMS (Data Base Management System) or the like. The DB 12 of this embodiment can be accessed in units of records, each of which includes multiple items for each customer.

[0024] In this embodiment, the DB 12 includes primary keys for various items such as company information, customer-related information, and sales activity information, as well as an update key, which is a column (item) indicating the last update information. FIG. 1(b) shows an example of this update key. In this embodiment, the update key includes a session ID (identification), a timestamp indicating the time of access, and a user ID. This update key is updated every time the data of the record is updated. The update range of this update key may be partial or complete. In this embodiment, when data is acquired from DB 12 in response to an update instruction from terminal 3, the update key at the time of data acquisition is acquired and stored.

[0025] Of these, the session ID is a unique character or number that is added when DB server 1 is accessed. The timestamp indicates the time of the first access using the session ID. In the example of Figure 1(b), the time is set in the order of year, hour, minute, and second, but shorter times such as milliseconds or microseconds may also be set. The user ID is the ID of the user who updated the application. This user ID may indicate the user or terminal 3 who accessed the AP server 2, and may be associated with the task. This session ID is a unique ID set by the DB server 1. This session ID may be the ID of the task session set by the AP server 2 when the terminal 3 accesses it, or may be another ID set by the DB server 1.

[0026] Here, the control unit of the DB server 1 can function as the detection unit 10 or the update processing unit 11 by expanding a control program stored in the ROM or HDD of the storage unit into the RAM and executing it. Note that a part or any combination of these functional configurations may be configured using FPGA or other circuits.

[0027] [DB update operation processing by DB update operation system X] Next, the DB update operation process using the DB update operation system X according to the embodiment of the present invention will be described in more detail with reference to FIGS. In the DB update operation processing according to this embodiment, the system detects that multiple tasks have updated the same data at the same time for a task that updates DB12. It then detects that DB12 has been updated by the task that first performed the update operation. In this situation, the system updates DB12 by reflecting only the update content of the task that first performed the update operation in DB12. Below, the DB update operation processing by this DB update operation system X will be explained in detail for each step using the flowchart in Fig. 2. These processes are mainly carried out by the control unit of the DB server 1, which executes a control program stored in the storage unit using hardware resources.

[0028] First, in step S101, the detection unit 10 performs an update operation data acquisition process. Referring to Figure 3(a), when starting the update operation, the user of terminal 3 accesses AP server 2 via an app, web browser, etc. (hereinafter simply referred to as "app") and performs an operation to display on display unit 32 data on various items such as sales activity information to be updated (hereinafter referred to as "update operation data"). In the example in Figure 3, user "AAA" updates information on sales activities for a customer identified by customer code "10001" on the app from terminal 3. In this example, another user "BBB" also updates information on sales activities for the same customer on another terminal 3 at almost the same time.

[0029] AP server 2 obtains information about this operation using task A, which is the processing unit of user "AAA"'s session, and sends a query command to DB server 1 to obtain the update operation data. Meanwhile, AP server 2 also obtains information about the operation using task B, which is the processing unit of user "BBB"'s session, and sends a query command to DB server 1 to obtain the update operation data. In other words, AP server 2 executes tasks A and B at the same time.

[0030] Then, the detection unit 10 of the DB server 1 acquires update operation data corresponding to these tasks A and B from the DB 12, and transmits it to the AP server 2. This update operation data may be, for example, data corresponding to items indicated by multiple primary keys. Specifically, in the example of record T-1 in FIG. 3(a), for the customer with customer code "10001," the same data corresponding to the primary keys "item 1," "item 2," and "item 3" are acquired by tasks A and B, respectively. That is, in this example, both tasks A and B acquire the same update operation data. The AP server 2 that receives this update operation data renders "Item 1," "Item 2," and "Item 3" as in form F-1 and displays them on the display unit 32 of the terminal 3 corresponding to tasks A and B, respectively.

[0031] Then, the detection unit 10 acquires the update key used when acquiring the update operation data. According to Figure 3(a), the content of this update key is "s001" for both tasks A and B. In this example, this update key "s001" is the "update key acquired when acquiring data for the update operation."

[0032] Next, in step S102, the detection unit 10 performs a data edit update instruction process. Here, the users "AAA" and "BBB" use the input unit 31 and display unit 32 of their respective terminals 3 to edit the data for each item in the update operation data on the GUI of the application, and press the update button. Referring to FIG. 3(b), in this example, "Item 1" for the customer is updated on Form F-2 corresponding to Task A for User "AAA." The AP server 2 detects this, acquires the edited data, and sends it to the DB server 1. The detector 10 of the DB server 1 acquires this updated data.

[0033] Next, in step S103, the detection unit 10 performs the latest updated key acquisition process. Here, the detection unit 10 acquires the latest updated key from the DB 12.

[0034] Next, in step S104, the detection unit 10 determines whether the update key used when acquiring the data is the latest update key. Here, the detection unit 10 compares the update key acquired when the task acquired data for the update operation with the latest update key included in the DB 12. If the update key acquired when the data was acquired matches the latest update key, the detection unit 10 determines Yes. In the example of FIG. 3(b), for task A, the key acquired at the time of data acquisition is "s001", so the detection unit 10 determines Yes.

[0035] On the other hand, in other cases, that is, when the update key used when the data was acquired does not match the latest update key, the detection unit 10 determines the answer as No. If the answer is Yes, the detection unit 10 advances the process to step S105. If the answer is No, the detection unit 10 advances the process to step S108.

[0036] If the update key used when the data was acquired matches the latest update key, the update processing unit 11 performs DB data update processing in step S105. If the comparison results in a match, the update processing unit 11 determines that this is the task that performed the update operation first, and performs the update processing of the DB 12. Here, the update processing unit 11 reflects only the update content of the task that performed the first update operation in the DB 12. This enables the update processing unit 11 to perform update processing on the DB 12. 3(b), as in record T-2, the data in "item 1" is updated in response to task A. Then, the detection unit 10 changes the update key to "s002".

[0037] Next, in step S106, the update processing unit 11 performs an update completion notification process. The update processing unit 11 notifies the AP server 2 that the update has been completed. The AP server 2 receives this information, reflects the completion of the update on the GUI of the application on the terminal 3, and notifies the user.

[0038] Next, in step S107, the update processing unit 11 performs an update key acquisition process. Here, the update processing unit 11 acquires the above-mentioned update key "s002" in the record T-2 of the customer code "10001". Thereafter, the update processing unit 11 ends the DB update operation processing.

[0039] In this way, if the update key used when the data was acquired does not match the latest update key, the update processing unit 11 performs an update-impossible presentation process in step S108. 3(c), when task B updates "item 2" even though task A has already updated "item 1," the update key used when task B acquires data in DB 12 does not match the latest update key on DB 12. In this case, the detection unit 10 can detect that task A, which is a different task, has updated DB 12 first, and determines "No" in step S104 described above.

[0040] In this example, the update key used when the data for task B of user "BBB" was acquired was "s001", but the latest update key was also "s001". In other words, the detection unit 10 detects that another task is updating DB 12.

[0041] In this way, if the update keys do not match, the update processing unit 11 determines that the task performed the update operation later and does not perform the update process. In other words, the update processing unit 11 does not update the DB 12 for the task that performed the update operation later.

[0042] If the update processing unit 11 does not perform the update processing, it notifies that the data has been updated by the task that first performed the update operation. At this time, the update processing unit 11 acquires not only the session ID of the DB 12 of the update key, but also information at the time of update, such as a timestamp and the user ID of the person who updated, and displays a message that the update was not successful.

[0043] Specifically, the update processing unit 11 issues an alert to the effect that the update was not possible, and presents information at the time of update including the previous update information of the latest update key, the session ID of DB 12, a timestamp, and the user ID of the updater, or any combination thereof, thereby enabling the user to determine when and who last updated the data. 4 shows an example of a screen 500 that detects that another task is updating the database for task B of user "BBB" and notifies the user that an update occurred at the same time. In this example, the app can refresh the screen, i.e., redisplay it, and prompt the user to refresh it again. This completes the DB update operation process.

[0044] To further explain, when the user "BBB" involved in task B performs an operation to redisplay the screen on the GUI of terminal 3, the AP server 2 acquires this operation and notifies the DB server 1. Then, the DB server 1 acquires the update operation data from step S101 described above, and compares the update keys again. Referring to Figure 3(d), this example shows the case where update operation data for customer code "10001" is obtained again. In this example, DB12 is in the state of record T-4, which is the same as record T-2 in Figure 3(b), so the value "1000" is obtained as "Item 1" in form F-4 as well. The "update key obtained when obtaining data" in this case is "s002."

[0045] Referring to FIG. 3(e), in the state of FIG. 3(d), if task B updates "item 2" by operation of user "BBB," the processing of steps S102 to S104 described above is executed again. This time, the update key acquired when the data was acquired and the latest update key are the same "s002." Therefore, the update key acquired when the data was acquired matches the latest update key, and therefore steps S105 to S107 described above are executed, and DB12 is updated. In this way, it is possible to maintain data consistency.

[0046] The above configuration can provide the following effects. In a conventional DB update operation system such as that described in Patent Document 1, when multiple tasks update the same data at the same time, the input contents of the task that performed the update operation last are held in DB 12. In this case, due to the exclusive control of DB12, the task that performed the update operation first locks the table, so the task that performed the update operation later is made to wait and cannot perform the update. On the other hand, after the DB update process for the earlier update operation is completed, the DB update process for the later update operation becomes possible. However, because the later DB update process is executed regardless of the contents of the earlier DB update process, there is a possibility that the column updated in the earlier DB update process will be overwritten with a different value.

[0047] Figure 5 shows an example in which two tasks, Task A and Task B, acquire the same data using such a conventional DB update operation system, and then Task A updates "Item 1" and Task B updates "Item 2." FIG. 5(a) shows an example of a record T-6 for a customer with the initial customer code "10001" and a form F-6 for obtaining this as update operation data. Figure 5(b) shows an example of form F-7 when Task A updates "Item 1" and the record T-7 reflected in DB12. Figure 5(c) shows an example of form F-8 when Task B updates "Item 2," and record T-8 reflected in DB 12. As shown above, the DB update process of Task B does not know that Task A has updated the DB, so it overwrites the content of "Item 1" updated by Task A with the value when Task B retrieved the data, resulting in the update content of Task A being lost. In this way, there is a possibility that the data may become inconsistent with the data before the update.

[0048] In contrast to this, (1) a DB update operation system X according to an embodiment of the present invention is an update operation system that updates DB12, and is characterized by comprising a detection unit 10 that detects that DB12 has been updated by the task that performed the update operation first when multiple tasks update the same data at the same time for the task that updates DB12, and an update processing unit 11 that updates DB12 by reflecting only the update contents of the task that performed the update operation first, which is detected by the detection unit 10, in DB12.

[0049] With this configuration, when multiple tasks simultaneously update the same data in a program with the function of updating DB12, the first task detects that it is updating DB12 and reflects only the update content of the task that first performed the update operation in DB12, thereby updating the new data. That is, pseudo-exclusive control is performed in DB update operations, and if it detects that another task is updating DB12, the data is reacquired. As a result, when multiple tasks simultaneously update the same data, the update content of the task that first performed the update operation can be reflected in DB12. Therefore, from the time the app displays the screen until the data update is completed, the data to be updated is not updated by other tasks, and update processing can be performed on the latest data, eliminating data loss due to simultaneous updates. As a result, DB updates are updated first, maintaining data consistency with the data before the update and preventing inconsistencies. In addition, exclusive control can be performed using update queries, making it easy to perform exclusive control regardless of whether it is on a record-by-record or table-by-table basis.

[0050] Furthermore, (2) in the DB update operation system X according to the embodiment of the present invention, the update processing unit 11 does not update the DB 12 for a task that performed an update operation later, but notifies the task that performed the update operation first that the data has been updated, which is a DB update operation system as described in (1).

[0051] By configuring it this way, the person who performs the update operation later will not update the database, but will be notified that the data has been updated by the first task, thereby preventing unexpected data loss.

[0052] Furthermore, (3) in the DB update operation system X according to the embodiment of the present invention, DB12 includes an update key representing the previous update information in addition to the primary key, and the detection unit 10 compares the update key acquired by the task when acquiring data for the update operation with the latest update key included in DB12, and if the comparison by the detection unit 10 shows a match, the update processing unit 11 determines that the task is the one that performed the update operation first and updates DB12, but if they do not match, it determines that the task performed the update operation later and does not perform the update. This is characterized by being a DB update operation system as described in (1) or (2).

[0053] With this configuration, an update key indicating the previous update information is provided in addition to the primary key, and the update key held at the time of data acquisition during the update operation is compared with the latest update key on DB12, and if they match, the update process is carried out, but if they do not match, this means that another task has updated the data since the data was acquired, so the update process is not carried out.In this way, a specific method for preventing unexpected data loss can be used to realize a simpler system that is easier to implement during development.

[0054] Furthermore, (4) in the DB update operation system X according to the embodiment of the present invention, if the update processing unit 11 does not perform the update processing, it presents information at the time of update including the previous update information of the latest update key, the session ID of DB12, a timestamp, and the user ID of the updater, or any combination thereof, as an alert to the effect that the update was not possible, thereby enabling the user to determine when and who performed the last update, and is characterized as a DB update operation system described in any of (1) to (3).

[0055] With this configuration, if an update operation is performed later, the database will not be updated, and a notification will be sent that the same data was updated by another task at the same time. In this case, the last update information is displayed on the screen from the update key, and not only the DB12 session ID of the update key but also information at the time of the update, such as a timestamp and the user ID of the person who updated it, is added. The alert display notifying the user that the update could not be performed also displays when and by whom the last update was performed. This allows the user to immediately know where to check the reason for an unexpected data update. In other words, it is easy to check data updates that were made at the same time, as it is clear where to check. Furthermore, since the last update information can be obtained when checking whether the data can be updated, there is no need to query DB12 for the last update information when displaying the notification message.

[0056] Other Embodiments In the above embodiment, an example in which an update key is assigned to each record has been described. However, updates may be managed on a record-by-record basis using something like a table containing only update keys. This configuration can speed up access management depending on the configuration.

[0057] In the above embodiment, it is described that a comparison is made to determine whether the update key is the latest. However, a database update operation may be detected by comparing whether the session IDs of the update keys are the same. By configuring it in this way, comparisons can be made reliably even if there are effects from DB12 cache, etc.

[0058] Furthermore, in the above embodiment, it has been described that a task that has undergone an update operation is not updated simply. However, when the contents of the record at the time of updating the DB 12 are compared and the changed parts of the task that was updated later are different, only that item may be updated. By configuring it in this way, it is possible to perform update operations in a later task while maintaining data consistency.

[0059] Furthermore, in the above embodiment, the time until the update of a task after the subsequent update operation is performed is not taken into consideration. However, if an update is performed after a specific time, for example, several minutes or more, has passed since the update operation data was acquired by the task, the update may be rejected without comparison, and the update operation data may be acquired again automatically. By configuring in this way, it is possible to reduce the frequency of access to DB12, and to make more efficient use of computing resources and network resources.

[0060] In the above embodiment, an example in which a CRM system is used as the DB update operation system X has been described. However, the DB update operation system can be widely applied to other systems that perform update operations on the DB 12 on a record-by-record basis.

[0061] It goes without saying that the configurations and operations of the above-described embodiments are merely examples, and can be modified as appropriate within the scope of the present invention. [Explanation of symbols]

[0062] 1 DB Server 2. AP Server 3. Terminal 4 Network 10. Detection unit 11 Update processing section 12 DB 31 Input section 32 Display section 500 Screen Examples F Form T-table X DB update operation system

Claims

1. A database update operation system for updating a database, a detection unit that detects, when a plurality of tasks simultaneously update the same data, that the database has been updated by the task that first performed the update operation, for a task that updates the database; an update processing unit that updates the database by reflecting only the update content of the task that first performed the update operation detected by the detection unit in the database; A database update operation system characterized by:

2. The update processing unit: The database is not updated for tasks that perform update operations later, and the task that performed the update operation first notifies the task that the data was updated.

2. The database update operation system according to claim 1.

3. The database comprises: In addition to the primary key, it contains an update key that indicates the last update information. The detection unit comparing the update key acquired by the task when acquiring data for the update operation with the latest update key contained in the database; The update processing unit: If the comparison by the detection unit shows a match, it is determined that the task performed the update operation first and updates the database, and if they do not match, it is determined that the task performed the update operation later and does not perform the update process.

2. The database update operation system according to claim 1.

4. The update processing unit: If the update process is not performed, an alert is displayed to the effect that the update was not possible, and information at the time of the update including the previous update information of the latest update key, the DB session ID, the timestamp, and the user ID of the updater, or any combination thereof, is presented, allowing the user to determine when and who last updated the data.

4. The database update operation system according to claim 1, wherein:

Images