JP2016009345A - File management system, file management method, and file management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a file management system for automatically detecting a difference between source program files.SOLUTION: In a file management system configured of a first server and a second server, a first program file generated by the first server is transmitted to the second server, and allowed to operate as a second program file, and a third program file obtained by updating the first program file is generated by the first server, and the first program file is compared with the second program file by the first server and the second server, and when there does not exist any difference, the second program file is replaced with the third program file, and when there exists a difference, the second program file is not replaced with the third program file.

Description

  The present invention relates to a file management system, a file management method, and a file management program.

  Large-scale system development requires the development of numerous programs. In addition, many programmers are involved in program development, and each programmer develops a source program. Then, the final execution program is completed by combining the developed source programs. In order for each programmer to change the program without contradiction, it is necessary to manage the change history of the program under development, and a system that stores the management history in a storage area such as a server is known.

  In any system, program change work always occurs. For example, a defect is discovered by maintenance inspection, a source program for the countermeasure is created, and the original program is updated. The source program is also changed when new functions are added. For example, there is Patent Literature 1 as a technique related to program update. In the technology of Patent Document 1, the server checks whether the latest version of the application exists on the client. If the latest version does not exist on the client, the server stores an archive file including the latest version of the application. It is downloaded and installed (updated).

Japanese Published Patent No. 2003-162415

  In the prior art, when the latest version of the application software does not exist on the client, that is, even when there is a difference, the existing application software is automatically rewritten with the latest version of the application software.

  However, an SE (system engineer) or the like may find a problem (bug) in the program usage environment and make corrections to the source program file. Therefore, the source program file used on the usage environment side may differ from the source program file developed and managed on the development side (source program providing side).

  Also, depending on the content of the problem, for example, minor problems such as partial display failures on specific screens, the amount of correction per source program file is small, but a very large number (several hundreds or more) of source programs There are cases where files are modified and changed. Therefore, a very large number (several hundred or more) of source program files may be different between the use environment side and the development side.

  In order to eliminate this difference, it is necessary to compare the source program files one by one to determine whether or not there is a difference. Furthermore, it is necessary to determine what kind of difference exists in which part of the source program file where the difference exists. Compare all the source program files used on the local side (use environment) with the source program files on the development side (development environment), and check whether there is a difference and It is necessary to grasp, the amount of work is enormous, and the work time is very large. In addition, since the confirmation is performed manually, mistakes such as omission of confirmation always occur. This becomes a factor causing a fatal failure in operating the system. The fatal failures here include system down, partial or complete loss of management data, and inability to store various types of information, but this is part of the failure, and an unexpected failure may occur. is there.

  Accordingly, an object of the present invention is to provide a file management system capable of mechanically grasping differences in source program files and reducing human errors such as omission of confirmation.

  In order to solve the above-described problem, a file management system according to an embodiment of the present invention includes a first server and a second server, and transmits a first program file generated by the first server to the second server. The first server generates a third program file in which the first program file is updated, and the first server or the second server stores the first program file and the second program file. If there is no difference, the second program file is replaced with the third program file. If there is a difference, the second program file is not replaced with the third program file.

  In the present invention, since the difference between the source program files can be mechanically grasped, human errors such as omission of confirmation can be reduced. In addition, differences between a large number of source files can be extracted in a short time, and the differences can be quickly grasped. Furthermore, it is possible to grasp whether or not a problem has occurred when the contents of correction on the use environment side are applied to the source file corrected on the development side. In addition, the problem extraction accuracy is improved by accumulating the history of the problems that have occurred. Efficiency can be realized. Problems, configurations, and effects other than those described above will be clarified by the following description of embodiments.

FIG. 1 is a block diagram showing the overall configuration of a file management system according to an embodiment of the present invention. FIG. 2 is a block diagram showing the internal configuration of the server. FIG. 3 is a diagram illustrating a configuration example of programs and data stored in the development server. FIG. 4 is a configuration example of a source file history table showing the history of source files. FIG. 5 shows the structure of the file management program. FIG. 6 is a flowchart showing a first process in file management. FIG. 7 is a flowchart showing a second process in file management. FIG. 8 is a flowchart showing a third process in file management.

  Hereinafter, embodiments will be described with reference to the drawings. In the following description, various types of information may be described using an expression such as “management table”, but the various types of information may be expressed using a data structure other than a table. Further, the “management table” can be referred to as “management information” to indicate that it does not depend on the data structure.

  Further, the process may be described with “program” as the subject. The program is executed by a processor, for example, an MP (Micro Processor) or a CPU (Central Processing Unit), and performs a predetermined process. Note that the subject of processing may be a processor because the storage resource (for example, a memory) and a communication interface device (for example, a communication port) are used as appropriate. The processor may have dedicated hardware in addition to the CPU. The computer program may be installed on each computer from a program source. The program source may be provided by, for example, a program distribution server or a storage medium.

  Each element, for example, the controller can be identified by a number or the like, but other types of identification information such as a name may be used as long as the information can be identified. In the drawings and description of the present embodiment, the same reference numerals are given to the same parts. However, the present invention is not limited to the present embodiment, and any application examples that meet the idea of the present invention can be applied. Included in the scope. Further, unless specifically limited, each component may be plural or singular.

<Overall configuration of file management system>
FIG. 1 is a block diagram showing the overall configuration of a file management system according to an embodiment of the present invention. As a use case of the invention, a file management system 1 in a hospital is given.

  File management system 1 communicates network 25, W hospital 22 / Y hospital 23 / Z hospital 24, which connects A hospital main hospital 21a / A hospital B branch 21b / A hospital C branch 21c / A hospital D branch 21d by communication. And a development center 20 on the development side for developing programs used in each hospital.

  In a hospital, for example, A hospital main hospital 21a (hereinafter abbreviated as hospital 21a), a terminal 4 for doctors and nurses to use electronic medical records, a management server 212 for managing patient information and treatment records, A communication device 211 is provided that is connected between the terminal 4 and the management server 212 or the network 25 by communication.

  The development center 20 includes a development server 3 and a communication device 201 for connecting the development server 3 to the network 25/26 by communication.

  The source program files of the electronic medical record program for managing and controlling the above-described electronic medical records and the management program for managing patient information and treatment records are developed at the development center 20, and the version and revision for each source program file are also managed. It is common. However, the use environment of the program, that is, the SE (system engineer) in the local hospital 21a finds a bug (bug) in the program and the correction is applied to the source program file itself used in the local hospital 21a. Sometimes it is done. Therefore, the source program file used on the hospital 21a side (use environment) may differ from the source program file developed and managed on the development side (development center). Also, depending on the content of the problem, for example, even minor problems such as partial display failures on specific screens, the amount of correction per source program file is small, but a very large number (several hundreds or more) of sources In some cases, the program file is modified and changed at the local hospital 21a. Therefore, a very large number (several hundreds or more) of source program files are used on the hospital 21a side (use environment) and those managed on the development center 20 side (development environment) are different. The potential is great.

  In order to eliminate this difference, it is necessary to compare the source program files one by one to determine whether or not there is a difference. Furthermore, it is necessary to determine what kind of difference exists in which part of the source program file where the difference exists. It is necessary to check the existence of differences and grasp the contents of differences for all source program files used on the local hospital 21a side for such complicated work. Big. In addition, since the confirmation is performed manually, mistakes such as omission of confirmation always occur. This becomes a factor causing a fatal failure in operating the system. Here, fatal failures include system down, partial or complete loss of management data, and inability to store information such as treatment records.

  One embodiment of the present invention provides a system and method that can efficiently identify source program files that have differences. In the following description, the source program file may be referred to as a source file.

<Server internal configuration>
FIG. 2 is a block diagram showing the internal configuration of the server. The terminal 4 / management server 212 on the hospital 21a side and the development server 3 on the development center 20 side include the components of the CPU 31, the memory 32, the storage unit 33, the input unit 34, the output unit 35, the display unit 36, and the communication unit 37. Prepare.

  The CPU 31 is a processor that controls the entire apparatus. The memory 32 is a device that temporarily stores various programs and various data (tables) described later. The storage unit 33 is a device that permanently stores various programs and various data that will be described later, and is, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The input unit 34 is a device that accepts input, and is, for example, a keyboard.

  The output unit 35 is a device that outputs information and data, and is, for example, a speaker or a printer. The display unit 36 is a device that displays information and data, and is, for example, a liquid crystal display. The communication unit 37 is a device that connects another server or another device via a network (not shown). The above components are connected to each other via an internal bus. It should be noted that any component of the input unit 34, the output unit 35, and the display unit 36 may not be included in each device.

<Program data structure>
FIG. 3 is a diagram illustrating a configuration example of programs and data stored in the development server.

  An operating system (OS) 321, a communication program 322, a file management program 323, and a file update program 324 are stored in the memory 32 of the development server 3. An operating system (OS) 321 is basic control software for operating software such as application programs. The communication program 322 is a program that controls communication between the development server 3 and other servers and terminals. The file management program 323 is a program for managing the file name, creation date, update date, size, version, revision, and the like of the source file program. The file update program 324 is a program for updating the source file program, and transmits information such as update contents and revision changes to the file management program 323.

  In the storage unit 33 of the development server 3, a development source file (before modification) 331, a development source file (after modification) 332, a local use source file 333, a development source file (local update application version) 334, a problem analysis result file 335, a past problem occurrence history file 336 is stored. A development source file (before renovation) 331 is a development source file before resolving a found defect. When a new defect is discovered after refurbishment, a source for returning the refurbished source file to the original state It is a file. The development source file (after modification) 332 is a development source file that has been modified in order to eliminate the found defects.

  The local use source file 333 is the latest source file used locally (on the hospital 21a side). The development source file (local update application version) 334 is a source file to which the content updated locally is applied in order to solve the problem at the site (hospital 21a side). The problem analysis result file 335 is a result of analyzing a problem that has occurred, and is a file for managing analysis results (problem occurrence date, problem type, problem content, etc.). The analysis result is judged by the programmer to determine whether it is an acceptable problem or a fatal problem, and the problem including the determination result is stored and accumulated in the past problem occurrence history file 336 as a problem in executing the program. In this way, the past problem occurrence history file 336 is a file that summarizes problems in program execution that have occurred in the past.

<Source file history table>
FIG. 4 is a configuration example of a source file history table showing the history of source files.

  FIG. 4A shows a case where “there is no difference (no difference)” between the development source file (before modification) 331 and the local use source file 333. That is, the file content of the development source file (before modification) 331 and the file content of the local use source file 333 are completely the same.

  FIG. 4B illustrates a case where “there is a difference (with a difference)” between the development source file (before modification) 331 and the local use source file 333. That is, there is a difference in the file content of the local use source file 333 with respect to the file content of the development source file (before modification) 331, and a difference has occurred.

  This example shows an example in which four files “00001.script”, “00002.script”, “00003.script”, and “00004.script” exist as source files. Each file stores a file creation (update) date and time (for example, “2012/01/01 0:00:00”) and a file size (for example, “120 KB”). The file management program 323 compares the file creation (update) date and time or the file size to determine whether there is a difference.

  Among these four source files, there is a difference between the source file “00002.script” of the local use source file 333 and the source file “00002.script” of the development source file (before modification) 331. That is, the file creation (update) date and time of the source file “00002.script” in the development source file (before modification) 331 is “2012/01/01 0:00:00”, and the file size is “145 KB”. On the other hand, the file creation (update) date and time of the source file “00002.script” in the local use source file 333 is “2013/02/01 0:00:00”, and the file size is “151 KB”. The file names of these two files are the same, but the contents are different and a difference occurs.

<File management program structure>
FIG. 5 shows the structure of the file management program. The file management program 323 includes an input function unit 3231, a comparison function unit 3232, an update function unit 3233, and an abnormality detection / processing end function unit 3234.

The input function unit 3231 is a function unit that stores a development source file (before modification) 331 and a development source file (after modification) 332 provided by the development department in the management server 212 of the local environment (hospital 21a).
The comparison function unit 3232 is a function unit that compares the local use source file 333 and the development source file (before modification) 331 provided by the business system development department.
The update function unit 3233 is a function unit that applies the development source file (after modification) 332 to the local use source file 333 when no difference occurs in the comparison by the comparison function unit 3232. That is, the local use source file 333 currently used in the use environment (hospital 21a) is replaced with the development source file (after renovation) 332.
The abnormality detection / processing end function unit 3234 is a function unit that stops processing when a difference occurs.

  The file management program 323 can detect a difference by comparing the development source file (before modification) 331 provided by the development department with the local use source file 333 used in the use environment (hospital 21a). In addition, the file management program 323 makes a comparison, thereby eliminating a human error (missing confirmation). Further, since the file management program 323 operates on a high-speed server, the comparison process can be executed at high speed. Therefore, even if there are many source files to be compared, the comparison can be completed in a short processing time.

<First process of file management>
FIG. 6 is a flowchart showing a first process in file management. This process is a process for detecting a difference. This process may be performed on the use environment side (hospital 21a) or on the development side (development center 20). In this example, it is assumed that the operation is performed on the use environment side (hospital 21a). Although the processing subject is described as the CPU 31 of the server 212, it may be the server 212 main body (or the server 3 main body in the development environment (development center 20)). Further, a file management program 323 operating on the CPU 31 may be used.

  In S600, the CPU 31 starts processing. In S601 (input), the CPU 31 stores a development source file (before modification) 331 and a development source file (after modification) 332 provided by the development department in the management server 212 of the local environment (hospital 21a).

  In S602 (comparison), the CPU 31 compares the local use source file 333 and the development source file (before renovation) 331 provided by the business system development department. In S603 (determination), the CPU 31 determines whether or not the local use source file 333 and the development source file (before modification) 331 completely match. If it is determined that they match (Yes), the CPU 31 executes S604, and if it determines that they do not match (does not match) (No), it executes S605.

  In S604 (update), the CPU 31 applies the modified source file 332 to the local environment when no difference occurs. That is, the CPU 31 replaces (updates) the local use source file 333 with the development source file (after modification) 332. Then, the process ends. In S605 (abnormal termination), the CPU 31 immediately stops the process when a difference occurs.

  Through the above processing, the local use source file 333 in which a difference has occurred can be identified with respect to the development source file (before modification) 331. Therefore, only the source file in which no difference has occurred can be updated with the development source file (after modification) 332. In addition, since the locally used source file 333 in which the difference has occurred can be specified, it is possible to analyze a correction portion of the locally used source file 333 with respect to the development source file (after modification) 332.

<Second process of file management>
FIG. 7 is a flowchart showing a second process in file management. This process is a process for detecting a difference and determining whether or not the modified source file can be applied to the difference source file. This process may be performed on the use environment side (hospital 21a) or on the development side (development center 20). In this example, it is assumed that the operation is performed on the use environment side (hospital 21a). Although the processing subject is described as the CPU 31 of the server 212, it may be the server 212 main body (or the server 3 main body in the development environment (development center 20)). Furthermore, the file management program 323 thru | or the file update program 324 which operate | moves on CPU31 may be sufficient.

  In S700, the CPU 31 starts processing. In S701 (difference extraction), the CPU 31 compares the local use source file 333 with the development source file (before modification) 331, and extracts the difference.

  In S <b> 702 (difference patch to modified source), the CPU 31 applies and updates the extracted difference source part to the development source file (after modification) 332. In S703 (operation check), the CPU 31 checks the operation with the development source file (after modification) 332 to which the difference is applied.

  In S704, the CPU 31 determines whether there is a problem in the operation. If there is a problem in the operation (Yes), the CPU 31 executes S706, and if there is no problem (No), the CPU 31 executes S705. In S705 (storage / use), if there is no problem in operation, the CPU 31 uses the modified source to which the difference is applied in the local environment. Then, the CPU 31 displays the normal end on the display unit 36 and reports it to the file manager. In S <b> 706 (abnormal termination), the CPU 31 stops applying the difference when a problem occurs in the operation. Then, the CPU 31 displays an abnormal end on the display unit 36 and warns the file manager.

  As described above, the contents of the local correction (updated part of the source file) are applied to the development source file (after modification) 332 that has been modified by the development department. After the refurbishment) 332 can add on-site corrections. As a result, it is possible to reduce the man-hours for correcting the source file and shorten the development period.

<Second process of file management>
FIG. 8 is a flowchart showing a third process in file management. This process
(1) Detection of differences (2) Judgment of applicability of modified source files to differential source files (3) Accumulation of problem occurrence history (4) Judgment of whether problems are acceptable It is processing to do. This process may be performed on the use environment side (hospital 21a) or on the development side (development center 20). In this example, it is assumed that the operation is performed on the use environment side (hospital 21a). Although the processing subject is described as the CPU 31 of the server 212, it may be the server 212 main body (or the server 3 main body in the development environment (development center 20)). Furthermore, the file management program 323 thru | or the file update program 324 which operate | moves on CPU31 may be sufficient.

  In S800, the CPU 31 starts processing. In S801 (difference extraction), the CPU 31 compares the local use source file 333 and the development source file (before modification) 331, and extracts the difference. This process is the same as S701.

  In S <b> 802 (difference patch to modified source), the CPU 31 applies and updates the extracted difference source part to the development source file (after modification) 332. This process is the same as S702. In S803 (operation check), the CPU 31 checks the operation with the development source file (after modification) 332 to which the difference is applied. This process is the same as S703.

  In S804 (problem determination), the CPU 31 determines whether there is a problem in the operation. If there is a problem in the operation (Yes), the CPU 31 executes S806, and if there is no problem (No), the CPU 31 executes S805. In S805 (storage / use), the CPU 31 uses the modified source to which the difference is applied in the local environment. Then, the CPU 31 displays the normal end on the display unit 36 and reports it to the file manager. Report successful completion.

  In S806 (abnormality detection), the CPU 31 suspends the application of the difference and displays the abnormal end on the display unit 36 to warn the file manager when the abnormality is detected. And CPU31 analyzes a problem and grasps | ascertains the content. The CPU 31 stores the problem analysis result (problem analysis result file 335) in the storage unit 33. In S <b> 807 (acquisition of past problem history), the CPU 31 acquires a history of problems that occurred in the past (past problem problem history file 336) from the storage unit 33.

  In S808 (determination of past problem), the CPU 31 determines whether the problem that has occurred this time has occurred in the past. Judgment method is the item that the problem that occurred this time corresponds to the item (error name) and error type (fatal error, simple error, warning level, negligible level, etc.) in the problem history that occurred in the past CPU 31 determines whether or not is included. The history of problems that have occurred in the past is a criterion for determining whether the problem that has occurred is acceptable. This criterion is set by a developer (such as a programmer) first, added by the developer (such as a programmer) as appropriate, and each time a problem occurs in this process, the criterion (the past occurrence problem history file) 336) is updated. If the problem has occurred in the past (Yes), the CPU 31 executes S809. If the problem has not occurred in the past (No), the CPU 31 executes S810.

  In S809 (allowance determination), the CPU 31 determines whether the problem is acceptable. The determination method is determined by the above-described error type. For example, if the error type is “fatal error”, the CPU 31 determines that an unacceptable problem has occurred. If the error type is “warning level” or “ignorable level”, the CPU 31 determines that the problem is acceptable. If the problem is acceptable (Yes), the CPU 31 executes S810. If the problem is not acceptable (No), the CPU 31 executes S814.

  In S810 (acquisition of problem analysis result), the CPU 31 displays the content of the problem that has occurred on the display unit. An analyst (a programmer who is a developer, a quality assurance department member, etc.) analyzes the contents of a problem that has occurred and defines an error name and an error type for the problem. The analyst inputs the defined analysis result through the input unit 34, and the CPU 31 acquires the input result (problem analysis result).

  In S811 (allowance determination), the CPU 31 determines whether the problem is acceptable based on the problem analysis result (error type) acquired in S810. If the problem is acceptable (Yes), the CPU 31 executes S812. If the problem is not acceptable (No), the CPU 31 executes S813. In S812 (problem history update), the CPU 31 updates the problem history with the analysis result of the problem. The process of S813 is the same as the process of S812. In S814 (difference application cancellation), the CPU 31 cancels the difference application and displays an abnormal end on the display unit 36 to warn the file manager because it is a fatal problem.

  By accumulating problem occurrence histories through the above processing, it is possible to improve problem extraction accuracy and shorten problem solving time.

As described above, in the embodiment of the present invention,
(E1) Since differences in source files can be grasped mechanically, human errors such as omission of confirmation can be reduced.
(E2) A large number of source file differences can be extracted in a short time.
(E3) The location of the difference can be quickly grasped.
(E4) It is possible to grasp whether or not a problem has occurred when the contents of correction on the use environment side are applied to the source file corrected on the development side.
(E5) Accumulating problem histories improves the problem extraction accuracy.
There is an effect.

  In addition, this invention is not limited to an above-described Example, Various modifications are included. The above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment. Each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.

  Information such as programs, tables, and files for realizing each function may be stored in a recording device such as a memory, a hard disk, and an SSD, or a recording medium such as an IC card, an SD card, and a DVD. Further, the control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.

1: File management system 3: Development server 4: Terminal 20, 27: Data center (development side)
21: Hospital (user side)
25, 26: Network 31: CPU
32: Memory 33: Storage unit 34: Input unit 35: Output unit 36: Display unit 37: Communication unit 201, 211: Communication device 212: Management server 321: Operating system (OS)
322: Communication program 323: File management program 324: File update program 331: Development source file (before modification)
332: Development source file (after modification)
333: Local use source file 334: Development source file (local update application version)
335: Problem analysis result file 336: Past occurrence problem history file 3231: Input function unit 3232: Comparison function unit 3233: Update function unit
3234: Abnormality detection / processing end function part

Claims (12)

A file management system comprising a first server and a second server,
The file management system includes:
Sending the first program file generated by the first server to the second server to operate as a second program file;
The first server generates a third program file obtained by updating the first program file;
The first server compares the first program file and the second program file;
If there is no difference between the first program file and the second program file, replace the second program file with the third program file,
If there is a difference, the second program file is not replaced with the third program file. The file management system according to claim 1, wherein the first server of the file management system includes a first display unit.
The first server is displayed on the first display unit.
If there is no difference between the first program file and the second program file, a message to replace the program file is displayed.
When there is a difference, a file management system that displays that the program file is not replaced. The file management system according to claim 1,
If there is a difference between the first program file and the second program file, the first server generates a fourth program file reflecting the difference in the third program file;
The second server determines whether the fourth program file operates normally and transmits the determination result to the first server;
If the determination result is normal, the fourth program file is replaced with the third program file,
If the determination result is abnormal, the fourth program file is not replaced with the third program file. The file management system according to claim 3, wherein the first server of the file management system includes a first display unit.
The first server is displayed on the first display unit.
If the determination result is normal, a message indicating that the determination is normal and that the second program file is replaced with the fourth program file is displayed.
If the determination result is abnormal, a display indicating that the second program file is not replaced with the fourth program file is displayed. The file management system according to claim 3, wherein the first server is
Comparing the determination result with the history of problems occurring in the second server operation;
If the determination result is present in the problem history, the second program file is replaced with the fourth program file if it is acceptable by judging whether the problem is acceptable;
If the determination result does not exist in the problem history, it is determined whether it is acceptable by determining whether it is an acceptable problem, and the content of the problem that has occurred and the acceptable result are added to the problem history,
If acceptable, replace the second program file with the fourth program file;
The file management system, wherein the second program file is not replaced with the fourth program file when it is not acceptable. A file management method for a file management system comprising a first server and a second server,
The file management system includes:
Sending the first program file generated by the first server to the second server to operate as a second program file;
The first server generates a third program file obtained by updating the first program file;
The first server or the second server compares the first program file with the second program file;
If there is no difference between the first program file and the second program file, replace the second program file with the third program file,
If there is a difference, the second program file is not replaced with the third program file. A file management method for a file management system, characterized in that: The file management method for a file management system according to claim 1, wherein the first server of the file management system includes a first display unit,
The first server is displayed on the first display unit.
If there is no difference between the first program file and the second program file, a message to replace the program file is displayed.
A file management method for a file management system, characterized in that, if there is a difference, a message indicating that the program file is not replaced is displayed. A file management method for a file management system according to claim 1,
If there is a difference between the first program file and the second program file, the first server generates a fourth program file reflecting the difference in the third program file;
The second server determines whether the fourth program file operates normally and transmits the determination result to the first server;
If the determination result is normal, the fourth program file is replaced with the third program file,
If the determination result is abnormal, the fourth program file is not replaced with the third program file. A file management method for a file management system, comprising: The file management method for a file management system according to claim 3, wherein the first server of the file management system includes a first display unit,
The first server is displayed on the first display unit.
If the determination result is normal, a message indicating that the determination is normal and that the second program file is replaced with the fourth program file is displayed.
If the determination result is abnormal, a display indicating that there is an abnormality and that the second program file is not replaced with the fourth program file is displayed. The file management method for a file management system according to claim 3, wherein the first server is
Comparing the determination result with the history of problems occurring in the second server operation;
If the determination result is present in the problem history, the second program file is replaced with the fourth program file if it is acceptable by judging whether the problem is acceptable;
If the determination result does not exist in the problem history, it is determined whether it is acceptable by determining whether it is an acceptable problem, and the content of the problem that has occurred and the acceptable result are added to the problem history,
If acceptable, replace the second program file with the fourth program file;
A file management method for a file management system, wherein the second program file is not replaced with the fourth program file when it is not acceptable. A file management program for a file management system comprising a first server and a second server,
The file management program of the file management system is:
A function of transmitting the first program file generated by the first server to the second server and operating as the second program file;
The first server generates a third program file obtained by updating the first program file;
The first server to the second server compare the first program file with the second program file;
If there is no difference between the first program file and the second program file, the function of replacing the second program file with the third program file;
A file management program for a file management system, having a function of not replacing the second program file with the third program file when there is a difference. A file management program for a file management system according to claim 11,
The first server, when there is a difference between the first program file and the second program file, a function of generating a fourth program file reflecting the difference in the third program file;
A function of determining whether the second server operates normally by operating the fourth program file;
A function of transmitting the determination result to the first server;
If the determination result is normal, a function of replacing the fourth program file with the third program file;
A file management program for a file management system, having a function of not replacing the fourth program file with the third program file if the determination result is abnormal.

Images