JP5373723B2 - Shared file management system, control method thereof, and program - Google Patents

Description

  The present invention relates to a shared file management system, a control method therefor, and a program, and in particular, includes a server, a plurality of clients, and a network that interconnects them, and the server is accessible to each of the plurality of clients. The present invention relates to a shared file management system for storing files, a control method therefor, and a program.

  Conventionally, when editing a shared file stored on a server while sharing it with multiple clients, when editing the shared file with one client, the shared file cannot be edited with other clients (hereinafter referred to as “lock”). In general, it is assumed that the editing of the shared file has been completed on one client, and that it can be edited on another shared client (hereinafter referred to as the “unlocked state”). It is. Here, when checking out a shared file and editing it, "Check out" is the work that locks this shared file, and "Check in" is the work that finishes editing the shared file and unlocks this shared file. That's it.

  In this method, multiple clients can edit one shared file at the same time without causing data inconsistency. However, if one client is editing a shared file for a long time, Was unable to edit this shared file and was inefficient.

  In contrast, a technique has been proposed in which one shared file is divided into a plurality of partial areas, and access by a client is managed for each partial area (see, for example, Patent Document 1). In this technology, even when a partial area of a shared file is accessed for editing, the partial area may already be locked by one client. The client cannot edit the corresponding partial area, and even if it can be accessed, the client is forced to access in a read-only mode where editing is not possible. Therefore, users editing this shared file on one client must keep in mind check-in and check-out when editing the shared file so that this problem does not occur. .

JP 2005-301838 A

  However, not all users involved in editing shared files are accustomed to checking in and checking out, so users who check out to edit shared files check in after editing You may forget. In some cases, the shared file may be left unchecked as the server, the client that was editing, or the network that connects them goes down. In such a case, even if the editing work is finished, the shared file is left in a locked state for a long time, and the shared file cannot be managed efficiently.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a shared file management system, a control method for the shared file management system, and a program capable of managing shared files more efficiently. And

  The shared file management system according to the present invention locks a shared file that can be accessed by each of a plurality of clients via a network so that only the one client can edit the shared file based on an editing start request of the one client. State control means for setting the shared file to the unlocked state in which the locked state is released based on the editing end request from the one client, and whether the shared file is in the locked state or the unlocked state Status information storage means for storing status information representing the status information, and status information output means for outputting status information of the shared file stored in the status information storage means to each of the plurality of clients. .

Before SL state control means, after said editing termination request from one client has been made, this edit termination request is made until the predetermined time elapses, when said editing start request from a client is not made this shared file and unlock state, said in the case of the editing start request from one client has been made you this shared file and the locked state.

  Further, each of the plurality of clients may further include a communication unit that communicates with the one client that is editing the shared file among the plurality of clients via the network.

  Further, an editing start request from another client for the shared file in the locked state is received in advance, and when the shared file becomes unlocked in the state control means, the shared file is set to the locked state and only to the other client. Reservation means for editing the shared file may be further provided.

  Furthermore, it may be further provided with forcible ending means for forcibly setting the shared file in the unlocked state when an elapsed time after the shared file is set in the locked state reaches a threshold value.

The shared file management system control method according to the present invention is based on an edit start request or an edit end request of one of the plurality of clients for a shared file that can be accessed by each of the plurality of clients via a network. A state control step in which only the one client can edit the shared file or an unlocked state in which the locked state is released; and at least whether the shared file is in the locked state or the unlocked state Storing state information in a storage unit; and outputting the state information of the shared file stored in the storage unit to each of the plurality of clients , wherein the state control step includes the one client The editing end request was made from When the editing start request is not made from the one client before the editing end request is made and the predetermined time elapses, the shared file is unlocked, and the editing start request is sent from the one client. wherein the locked state and to Rukoto this shared file when made.

The program according to the present invention relates to a shared file that can be accessed by each of a plurality of clients via a network based on an edit start request or an edit end request of one of the plurality of clients. Storing state information including at least a state control function for setting the lock state in which the shared file can be edited or the unlock state in which the lock state is released, and whether the shared file is in the lock state or the unlock state And a function for causing each of the plurality of clients to output status information of the shared file stored in the storage means, and the status control function is configured to terminate the editing from the one client. After the request is made, this edit termination request is not made. When the editing start request is not made from the one client before the predetermined time elapses, the shared file is unlocked, and when the editing start request is made from the one client, a shared file and wherein the lock state and be Rukoto.

  According to the present invention, the state information including at least whether the shared file is in the locked state or the unlocked state is stored, and the client is operated by causing each of the plurality of clients to output the state information of the shared file. Since the user can easily grasp whether or not the shared file is being edited by another user, the shared file can be managed more efficiently.

  Also, when an editing end request is made from a client editing a shared file, the shared file is unlocked after waiting for a predetermined time after the editing end request is made. Even if the client that is editing the file accidentally requests to end editing, if that client requests to start editing again during the predetermined time, the shared file will be locked by another client. Can be prevented.

  In addition, each of the clients can communicate with the client editing the shared file via the network, so that the clients who want to edit the shared file negotiate with each other. Can do. This makes it possible to manage shared files more efficiently.

  In addition, when an editing start request is issued from any of a plurality of clients when the shared file is in the locked state, the shared file is reserved for editing by the client as soon as the shared file becomes unlocked. Can be efficiently performed.

  Further, when the elapsed time after the shared file is set to the locked state reaches a threshold value, the shared file is unlocked and the editing operation of the shared file is forcibly ended by the client having the shared file. It can be prevented that other clients cannot be edited after being edited for a long time.

It is a figure which shows the structure of the shared file management system which concerns on embodiment of this invention. It is a block diagram which shows the example of 1 structure of the server of the shared file management system which concerns on embodiment of this invention. It is a block diagram which shows the example of 1 structure of the client of the shared file management system which concerns on embodiment of this invention. It is a figure which shows the example of 1 structure of the shared file management table which the shared file management system which concerns on embodiment of this invention stores. It is a flowchart which shows the edit start routine which a server performs when the edit start request | requirement of a shared file is received from the client 2 in the shared file management system which concerns on embodiment of this invention. It is a figure which shows an example of the monitoring screen for confirming the state of the shared file displayed on the display part of a client in the shared file management system which concerns on embodiment of this invention. It is a flowchart which shows the edit completion routine which a server performs when the shared file management system which concerns on embodiment of this invention receives the edit completion request of a shared file from a client. It is a sequence diagram which shows an example of operation | movement of the shared file management system which concerns on embodiment of this invention. It is a flowchart which shows the forced termination routine which a server performs in the shared file management system which concerns on embodiment of this invention. It is a block diagram which shows the modification of the shared file management system which concerns on embodiment of this invention.

  Next, embodiments of the present invention will be described in detail with reference to the drawings. In each figure, the same numerals are given to the same component.

[Embodiment]
First, the configuration of the shared file management system 100 according to the embodiment of the present invention will be described with reference to FIGS. As shown in FIG. 1, a shared file management system 100 according to the present embodiment includes a server 10, N clients 20 (20-1 to 20-N), and a LAN (Local Area) that connects these to each other. Network) 30.

Among these, the server 10 includes a CPU, a storage device, an input / output device, and a communication interface (not shown), and functionally, as shown in FIG. 2, a storage unit 11, a state control unit 12, and a state information storage unit. 13, a reservation unit 14, a status information output unit 15, a forced termination unit 16, and a communication unit 17.
The storage unit 11 stores data such as a shared file that can be accessed by each of the clients 20 (20-1 to 20-N). Here, the shared file refers to a file that can be accessed by each of a plurality of computers (clients 20) via a network (LAN 30).
In response to an editing start request from the client 20, the state control unit 12 puts the shared file into a locked state in which only one of the clients 20-1 to 20-N can be edited, or an editing end request from the client In response to this, the lock state of the shared file is released to the unlocked state.
The state information storage unit 13 stores state information of a shared file including whether the shared file stored in the storage unit 11 is in a locked state or an unlocked state.
The reservation unit 14 makes a reservation so that when the client 20 receives an edit start request for a shared file in a locked state, the client 20 can edit the shared file as soon as the shared file is unlocked. is there.
The status information output unit 15 reads the status information stored in the status information storage unit 13 and causes the client 20 to output the status information.
When the shared file is checked out by one of the clients 20-1 to 20-N and a locked state has passed for a long time (for example, 10 hours or 20 hours), the forced termination unit 16 The file is forced to be unlocked.
The communication unit 17 realizes a function of performing communication with the clients 20-1 to 20-N via the LAN 30.

On the other hand, the client 20 includes a CPU, a storage device, an input / output device, and a communication interface (not shown), and functionally includes a display unit 21, an operation unit 22, and a communication communication unit 23 as shown in FIG. I have.
The display unit 21 displays various screens such as a display device.
The operation unit 22 inputs signals such as characters, numbers, symbols, and directions to a CPU (not shown) provided in the client 20 based on user operations such as a keyboard and a mouse.
The communication communication unit 23 implements a function of performing communication with the server 10 and other clients 20 via the LAN 30.

Next, the shared file status information stored in the status information storage unit 13 will be described.
FIG. 4 is a diagram illustrating an example of the structure of the shared file management table stored in the state information storage unit 13. As shown in FIG. 4, the shared file management table stored in the state information storage unit 13 includes a “shared file ID”, “flag F1”, “editor ID”, “flag F2”, “reserver ID”, and It contains a record consisting of a field called “update time”.
The “shared file ID” is an ID for uniquely identifying the shared file, and for example, a path of each shared file or a character string uniquely assigned to each shared file can be used.
The “flag F1” indicates whether or not the corresponding shared file has been edited by the client 20, that is, whether or not the shared file is in a locked state or an unlocked state. Specifically, the value “0” is input when the shared file is unlocked, and the value “1” is input when the shared file is locked.
“Editor ID” indicates an ID for uniquely identifying the client who is editing the shared file when the corresponding shared file is being edited. For example, the IP address of the client, the MAC Address, authenticated user name, etc. are entered. For this reason, when the value of the “flag F1” is “1”, other clients 20 other than the client 20 specified by the “editor ID” cannot edit the shared file. When the shared file is not being edited, the value of the “flag F1” is “0”, and the value of the “editor ID” field is NULL.
The “flag F2” is edited by another client when the shared file is being edited by a client, that is, when the value of the “flag F1” is set to “1” and is locked. It indicates whether or not a right is reserved. Specifically, the value “0” is input when the shared file is not reserved, and the value “1” is input when the shared file has already been reserved.
“Reserver ID” indicates an ID for uniquely identifying the client who reserves the editing right of the shared file when the editing right of the shared file is reserved. An IP address, a MAC address, an authenticated user name, and the like are input. Therefore, as for the shared file whose “flag F2” value is “1”, as soon as the editing operation is finished and the locked state is released, the client 20 specified by the “reserver ID” edits the shared file. Will be able to. If the shared file is not reserved, the value of the “flag F2” is “0”, and the value of the “reserver ID” field is NULL.
The “update time” indicates the time when the editing operation of the shared file corresponding to the corresponding record is started, or the last saving time in the case of the shared file stored during the editing operation. This is used when the forced termination unit 16 checks whether a long time has passed with the shared file being locked. When the shared file corresponding to the corresponding record is not being edited, the value of this field is NULL.
The status information storage unit 13 stores the status information of the shared file by inputting data into the shared file management table.

  Next, each operation in the shared file management system 100 will be described.

  First, when the user who operates the client 20 performs a predetermined operation such as clicking a shared file displayed on the display unit 21 and starts editing the shared file using an editing program, the sharing is performed. The operation of the file management system 100 will be described. As described above, when a user operating the client 20 tries to start a shared file editing operation, the communication communication unit 23 transmits a signal notifying the server 10 of a shared file editing start request. When the editing start request is notified from the client 20, the server 10 refers to the shared file management table and determines whether to approve the editing work. The contents will be described below with reference to a flowchart.

FIG. 5 is a flowchart showing an editing start routine executed when the server 10 receives a shared file editing start request from the client 20 via the LAN 30 in the shared file management system 100 according to the embodiment of the present invention.
First, when the server 10 receives a shared file ID and an ID for specifying the client 20 (hereinafter referred to as “client ID”) together with the shared file ID from the client 20, the client 20 displays the shared file management table. With reference, “flag F1” and “flag F2” of the record corresponding to the corresponding shared file are read (step S100), and it is checked whether or not the value of “flag F1” is “0” (step S110).

As a result, when the value of the read “flag F1” is “0” (step S110; YES), it is determined that this shared file is not being edited, and the process of checking out this shared file, ie, this client A process of setting the lock state so that 20 can edit the shared file exclusively is performed.
Specifically, first, the state control unit 12 updates the value of the “flag F1” of the record associated with the shared file ID to “1” and sets the client ID of the client 20 to “editor ID”. Then, the current time is input as “update time” (step S120). In this way, by updating the value of “Flag F1” to “1”, the state control unit 12 restricts clients 20 other than the client 20 specified by “Editor ID” from accessing this shared file. To do.
Next, the communication unit 17 downloads the corresponding shared file to the client 20 (step S130), and notifies all the clients 20-1 to 20-N that the shared file is being edited. (Step S140), and the editing start routine ends.

As a result of the processing in step S140, the fact that the corresponding shared file is being edited is output as follows in the clients 20-1 to 20-N.
FIG. 6 shows an example of a case where a plurality of shared files related to the building management system are targeted, and the state of the shared file displayed on the display unit 21 of the client 20 in the shared file management system 100 according to the embodiment of the present invention. An example of a monitoring screen for confirming FIG. 6A shows a monitoring screen when all shared files are unlocked, and FIG. 6B shows a monitoring screen when a certain shared file is locked. As shown in FIG. 6, an icon indicating the status of the shared file is displayed next to the shared file name of each shared file displayed for each building area. When the icon is unlocked, the icon is a white square. When the icon is locked, it changes to a square icon with an “x” mark. Therefore, the user operating the client 20 can confirm whether or not the shared file is being edited by opening this screen and confirming the state of the icon in front of the shared file.
Also, the user operating the client 20 edits the shared file using the function of the communication communication unit 23, for example, by clicking on the shared file name of the shared file that is being edited and locked. A message can be transmitted to the client 20 or a telephone call can be made. In this way, by opening the shared file monitoring screen on the client 20 and performing a predetermined operation on the screen, the users who wish to edit the shared file can communicate with each other and unlock the shared file. Can be negotiated.
In this embodiment, a tree structure monitoring screen is described as an example. However, any display form may be used as long as the shared file status can be confirmed. May be displayed.

Returning to the description of the processing in step S110 in FIG.
In the process of step S110, when the value of “flag F1” is “1” (step S110; NO), it is determined that this shared file is being edited, and the value of “flag F2” is “0”. It is further determined whether or not there is (step S150).
When the value of “Flag F2” is “0” (step S150; YES), it is determined that the shared file has not been reserved yet, and the reservation unit 14 performs a reservation process. Specifically, the value of “Flag F2” is updated to “1”, and the client ID of this client 20 is input to “Reserver ID” (step S160), and the editing start routine ends. The timing at which the authority to edit the shared file is transferred from the client 20 currently editing to the client 20 that has performed the reservation process will be described later. In addition, before performing the reservation process of step S160, you may perform the process which displays a pop-up on the display part 21 of the client 20, and confirms a user's will about whether to make a reservation.
On the other hand, when the value of “flag F2” is “1” (step S150; NO), it is determined that this shared file has already been reserved, and the reservation unit 14 starts editing without performing reservation processing. End the routine.

  Next, the shared file when the user who operates the client 20 ends the editing work by ending the program for editing the shared file or closing the shared file edited on the program. The operation of the management system 100 will be described. As described above, when the user operating the client 20 finishes the editing operation of the shared file, the communication communication unit 23 transmits a signal notifying the server 10 of the editing end request of the shared file. When the editing end request is notified from the client 20, the server 10 refers to the shared file management table, refers to whether or not reservation processing has been performed on the shared file, and releases the lock state of the shared file. To do. The contents will be described below with reference to a flowchart.

FIG. 7 is a flowchart showing an editing end routine executed when the server 10 receives a shared file editing end request from the client 20 in the shared file management system 100 according to the embodiment of the present invention.
First, the state control unit 12 checks again whether there is an editing start request (that is, cancellation of an editing end request) from the same client 20 again within a predetermined time (for example, 10 seconds or 20 seconds) (step S200).
When an edit start request is received again from the same client 20 within a predetermined time (step S200; NO), the edit end routine is ended without performing a check-in described later. Therefore, the lock state of the shared file is not released, and the same client can continuously edit the shared file.
As described above, the state control unit 14 accepts only the edit start request from the same client 20 for a predetermined time because the user operating the client 20 accidentally ends the program or the like. This is to prevent the shared file from being locked by another client 20 when the editing operation is finished, and the editing cannot be performed.

On the other hand, when there is no editing start request again from the same client 20 within a predetermined time (step S200; YES), in order to check in this shared file, that is, the lock state of this shared file is released and the unlock state is set. Therefore, the following processing is performed.
First, the “flag F2” of the record of the corresponding shared file is read with reference to the shared file management table (step S210), and it is determined whether or not the value of this “flag F2” is “0” (step S210). S220).
When the value of the read “flag F2” is “0” (step S220; YES), it is determined that this shared file is not reserved, and the state control unit 12 performs a check-in process.
Specifically, the state control unit 12 updates the value of “Flag F2” to “0”, updates the value of “Editor ID” to NULL, and updates the value of “Update Time” to NULL (Step S1). S230). Further, the communication unit 17 notifies all clients that the shared file can be edited (step S240), and the editing end routine ends. Here, when the communication unit 17 notifies the clients 20-1 to 20-N that the shared file can be edited, as described above, the display unit 21 of the clients 20-1 to 20-N. When the shared file status monitoring screen is opened and the icon next to the shared file name of the shared file is confirmed, it can be seen that the square marked with “X” has changed to a white square. Therefore, the user can easily determine whether the corresponding shared file is being edited by opening this monitoring screen.

On the other hand, when the value of the read “flag F2” is “1” (step S220; NO), it is determined that the shared file is reserved, and the state control unit 12 reserves editing of the shared file. The process of approving the editing to the client 20 that has been performed is performed.
Specifically, the state control unit 12 inputs “reserver ID” in “editor ID”, updates “reserver ID” to NULL, and updates the value of “flag F2” to “0”. (Step S250). The communication unit 17 downloads the shared file to the reserved client 20 and notifies that the editing request for the shared file has been approved (step S260), and ends the editing end routine. Here, as a method for notifying the reserved client 20 that the editing request has been approved, for example, when the above-described shared file monitoring screen is opened on the display unit 21 of the reserved client 20. And a method for displaying that the editing request has been approved by pop-up or generating a chime. As described above, since the process of notifying the reserved client 20 that the editing request has been approved is performed, the user operating the client 20 bothers to check the status of the shared file. This makes it possible to concentrate on other tasks while waiting for a notification that the shared file editing request has been approved.

Next, an example of the operation of the shared file management system 100 according to the embodiment of the present invention will be described with reference to the sequence diagram shown in FIG.
For convenience of explanation, in this sequence diagram, only two clients, the client 20-1 and the client 20-2, are drawn, but it goes without saying that the number of clients 20 is not limited to two.

  First, when a user using the client 20-1 executes a predetermined operation for starting editing of a shared file stored in the server 10, the client 20-1 requests the server 10 to start editing. Is transmitted (step S300), and the server 10 executes the editing start routine described with reference to FIG. 5 (step S310). Here, it is assumed that the shared file for which an edit start request has been made has not been edited by anyone, and the value of the “flag F1” of the corresponding record in the shared file management table is “0”. Then, since the editing start request is approved, the normal checkout process described in steps S120, S130, and S140 of FIG. Then, the client ID of the client 20-1 is input to the “editor ID”, the current time is input to the “update time”, the shared file is downloaded to the client 20-1, and the clients 20-1, 20 are downloaded. -2 is notified that the shared file has been locked.

  Next, when the user operating the client 20-2 performs an operation for editing the same shared file, an edit start request for the shared file is transmitted from the client 20-2 to the server 10 (step S1). In step S320, the server 10 executes the editing start routine described with reference to FIG. 5 again (step S330). Here, the shared file for which an edit start request has been made has already been edited by the client 20-1, and the value of the “flag F1” of the corresponding record in the shared file management table is “1”. Therefore, an edit start request from the client 20-2 is not accepted, and it is determined whether or not the value of “flag F2” is “0” in step S150 of FIG. If this shared file has not yet been reserved for editing and the value of “Flag F2” is “0”, the value of “Flag F2” is updated to “1” in Step S160 of FIG. Enter the client ID of the client 20-2 in “Reserver ID”.

  Next, when the user operating the client 20-1 performs an operation of overwriting and saving the downloaded shared file, the shared file is uploaded to the server 10 (step S340). Further, when the editing operation is completed by closing the shared file on the editing program, an editing end request is transmitted from the client 20-1 to the server 10 (step S350), and the server 10 uses FIG. The editing end routine described above is executed (step S360). Here, since the client 20-2 has already made a reservation so that the shared file can be edited next, and the value of the “flag F2” of the corresponding record in the shared file management table is “1”, step S250 in FIG. The value of “Reserver ID” is input to “Editor ID” of the corresponding record in the shared file management table, the value of “Reserver ID” is updated to NULL, and the value of “Flag F2” is set to “0”. After the update, in step S260 of FIG. 7, the shared file is downloaded to the client 20-2 and the editing of the shared file is notified. As a result, the user operating the client 20-2 can immediately grasp that the editing has been approved as soon as editing by the client 20-1 is completed, and can immediately start editing the shared file.

When the user operating the client 20-2 performs an operation of overwriting and saving the shared file, the shared file is uploaded to the server 10 (step S370). Further, when the editing work is ended by closing the shared file on the editing program, an editing end request is transmitted from the client 20-2 to the server 10 (step S380), and the server 10 again returns to FIG. The editing end routine described above is executed (step S390). Here, in the process of step S360 described above, the value of “flag F2” is updated to “0” in the corresponding record of the shared file management table, and the reservation for the shared file is released. Therefore, an affirmative determination is made in step S220 of FIG. 7, and the value of “flag F1” of the corresponding record in the shared file management table is updated to “0” in step S230 of FIG. The value of “ID” is updated to NULL, the value of “update time” is updated to NULL, and the fact that the shared file can be edited to the clients 20-1 and 20-2 in step S240 of FIG. Notice. As a result, the user operating the clients 20-1 and 20-2 can grasp that the shared file can be edited without bothering accessing the server 10 and making an inquiry.
As described above, the shared file upload (step S370) and the shared file editing end request (step S380) are independent of each other. This is because, in preparation for when the client 20 is down, the user has a desire to frequently upload the edited contents to the server 10 even during the editing of the shared file.

Finally, a description will be given of a mechanism in which the forced termination unit 16 forcibly releases the locked state of a shared file that has been locked for a long time.
FIG. 9 is a flowchart showing a forced termination routine executed by the server 10. This flowchart is executed every predetermined time (for example, every several tens of minutes or every several hours).

First, one record is extracted from the shared file management table (step S400). Here, as a record to be extracted, it is only necessary to extract and extract the record stored in the shared file management table with the value of “flag F1” being “1”, that is, the locked state. .
Next, the “update time” of this record is read, and the elapsed time ΔT from the “update time” is calculated (step S410). As this “update time”, the time when the editing operation of the corresponding shared file is started, or the time when the file is overwritten in the middle of the editing operation is input last. For this reason, the elapsed time ΔT indicates the elapsed time since the start of the editing work when the shared file being edited has never been overwritten and saved, and the last time for the shared file overwritten and saved during the editing work. Indicates the elapsed time since it was overwritten.

  Subsequently, the elapsed time ΔT calculated in this way is compared with a threshold value T1 and a larger threshold value T2 (step S420). Here, the threshold value T2 is set as a time that can be predicted that the shared file is locked even though the editing operation of the shared file has already been completed, and is set to 10 to 20 hours, for example. The threshold T1 is set as a time shorter by about 1 to 2 hours than the threshold T2, and is used to give a notice before the shared file in the locked state is forcibly set to the unlocked state.

When the elapsed time ΔT is less than the threshold value T1 (step S420; ΔT <T1), the shared file is not locked for a long time, so the process related to forced termination is not executed.
When the elapsed time ΔT is equal to or greater than the threshold T1 and less than the threshold T2 (step S420; T1 ≦ ΔT <T2), the elapsed time ΔT becomes equal to or greater than the threshold T2 after a while, and the shared file editing process is forcibly terminated as described later. Therefore, a pop-up prompting the user editing the shared file corresponding to the record to save the shared file is displayed (step S430). The pop-up display content may be displayed with a message prompting to save the shared file and the remaining time until the forced termination process is executed.
When the elapsed time ΔT is equal to or greater than the threshold T2 (step S420; T2 <ΔT), it is determined that the shared file is left in a locked state even though the editing operation of the shared file has already been completed. Performs forced termination processing. Specifically, by executing the editing end routine described with reference to FIG. 7 (step S440), when there is no reservation for the shared file, the lock state is released and the unlock state is set. On the other hand, when there is a reservation, the editing work is approved for the client who made the reservation. By executing such processing, it is possible to suppress a situation in which the shared file is locked by the one client 20 for a long time and the other clients 20 cannot be edited. At this time, step S200 in FIG. 7 for accepting an edit request from a client that is editing only for a predetermined time may be omitted. After executing the editing end routine, the user who has locked the shared file for a long time is notified by pop-up that the editing of the shared file has been forcibly ended (step S450).

  After confirming that the processes in steps S400 to S450 have been executed for all the records in the shared file management table (step S460), the forced termination routine is terminated. In this way, if there is a shared file that has been locked for a long time by one client 20, the locked state is forcibly released, so that the shared file can be edited efficiently. . Further, since the user who is editing the shared file is notified to save the shared file before forcibly releasing the lock state (step S430), the editing operation of the shared file is continued. Nevertheless, forcibly releasing the lock state can also be suppressed.

  According to the shared file management system 100 according to the present embodiment described above, the server 10 sets the value of “flag F1” indicating whether the shared file is in the locked state or the unlocked state in the shared file management table. When the value of this “flag F1” is updated, it is notified to all clients 20 (step S140 in FIG. 5 and step S240 in FIG. 7). The user of the client 20 can easily edit the shared file by opening a monitoring screen for managing the status of the shared file on the display unit 21 and checking the status of the icon in front of the shared file. Whether or not there is can be grasped. Therefore, the shared file can be managed efficiently.

  Further, in the shared file management system 100 according to the present embodiment, even when the client 20 that has edited the shared file makes an editing end request to the server 10, the server 10 keeps the predetermined time (for example, 10 seconds). Within 20 seconds), it is confirmed again that there is no editing start request from the same client 20 (step S200 in FIG. 7). For this reason, even if a user editing a shared file accidentally ends the shared file editing operation, the user can perform an operation for starting the shared file editing operation again within a predetermined time. Then, it can be prevented that the shared file is locked by another client 20 and cannot be edited.

  Furthermore, in the shared file management system 100 according to the present embodiment, the user operating the client 20 opens the shared file monitoring screen shown in FIG. The users who wish to edit the shared file can communicate with each other and negotiate to release the lock state of the shared file. For this reason, the shared file can be edited efficiently.

  Further, in the shared file management system 100 according to the present embodiment, the server 10 receives a request to start editing from another client 20 when the shared file is being edited and locked by the client 20 with the shared file. Next, a reservation is made so that the shared file can be edited (step S160 in FIG. 5), and as soon as the editing operation is completed, the shared file is downloaded and notified that the editing has been approved (FIG. 7). Steps S250 and S260), the shared file can be edited efficiently.

  Furthermore, in the shared file management system 100 according to the present embodiment, the server 10 is locked for a long time by one client 20 of the shared files by executing the forced termination routine described in FIG. If there is something, the locked state is forcibly released, so that the shared file can be edited efficiently.

[Modification]
In the shared file management system 100 according to the above-described embodiment, the storage unit 11, the state control unit 12, the state information storage unit 13, the reservation unit 14, the state information output unit 15, and the forcible termination unit 16 are: Although all have been described as being provided in the same server 10, they may be provided in different servers as shown in FIG.
In the example illustrated in FIG. 10, the server 10-1 includes the storage unit 11, and the server 10-2 includes the state control unit 12, the state information storage unit 13, the reservation unit 14, the state information output unit 15, and the forced termination unit 16. It has.
In this case, the server 10-1 executes the process of downloading the shared file described in step S130 of FIG. 5 and step S260 of FIG. 7 to the client 20, and the server 10-2 performs the other processes. It will be.

Further, in the shared file management system 100 according to the above-described embodiment, as described in the processing of step S140 in FIG. 5 and step S240 in FIG. 7, the state of the shared file is between the locked state and the unlocked state. Although it has been described that the server 10 notifies all the clients 20 when it fluctuates, it may not be notified. In this case, for example, each of the clients 20 sends an SQL to the server 10 for inquiring about a change in the shared file management table every predetermined time (for example, every few minutes or every several tens of minutes). That's fine.
Alternatively, the notification from the server 10 to all the clients 20 is only that the shared file management table has changed, and each of the clients 20 (20-1 to 20-N) has specific contents triggered by this. It is good also as what transmits to the server 10 the SQL sentence which inquires.

  In the shared file management system 100 according to the above-described embodiment, the server 10 and the clients 20 (20-1 to 20-N) are connected via the LAN 30, but not via the LAN 30 but via the Internet network. It may be connected.

  Furthermore, in the editing end routine of FIG. 7 of the above-described embodiment, the process of step S200 for accepting an editing start request (cancellation of editing end request) from a client who is editing the shared file for a predetermined time may be omitted. .

  Further, in the shared file management system 100 according to the above-described embodiment, it has been described that reservation can be made only by one client 20, but reservations may be accepted from a plurality of clients 20, and in this case, for example, The client 20 may be able to edit in the order in which reservations are received.

  Furthermore, in the shared file management system 100 according to the above-described embodiment, the server 10 includes the reservation unit 14 and the forced termination unit 16, but may not include these.

  In the above-described embodiment, the present invention has been described as a form of the shared file management system 100. However, a form of a control method of the shared file management system 100 or a form of a program incorporated in the shared file management system 100 may be used.

  In the above-described embodiment, each functional unit included in the server 10 and the client 20 includes hardware resources such as an interface with a CPU, a storage device, and an external device included in the server 10 and the client 20, and these hardware units. This can be realized by cooperation with a program that controls the hardware resources. A program for realizing the control method of the shared file management system 100 is provided in a state of being recorded on a recording medium such as a flexible disk, a CD-ROM, a DVD-ROM, or a memory card. The CPU writes the program read from the recording medium into the storage device, and executes the processing described in the embodiment according to the program.

  The present invention can be used in the manufacturing industry of shared file management systems.

  10 (10-1, 10-2) ... server, 11 ... storage unit, 12 ... state control unit, 13 ... state information storage unit, 14 ... reservation unit, 15 ... state information output unit, 16 ... forced termination unit, 17 Communication unit 20 (20-1 to 20-N) Client 21 Display unit 22 Operation unit 23 Communication unit 30 LAN 100 Shared file management system

Claims (6)

With respect to a shared file that can be accessed by each of a plurality of clients via a network, a lock state in which only the one client can edit the shared file is set based on a request to start editing of the one client, and from the one client A state control means for bringing the shared file into an unlocked state in which the locked state is released based on the editing end request;
State information storage means for storing state information indicating whether the shared file is in a locked state or an unlocked state;
Status information output means for causing each of the plurality of clients to output status information of the shared file stored in the status information storage means ,
The state control means includes
After the editing end request is made from the one client, the shared file is unlocked when the editing start request is not made from the one client until a predetermined time elapses after the editing end request is made. shared file management system as a state, said when the edit start request from a client is made, characterized in that the shared file in a locked state. The shared file management system according to claim 1,
Each of the plurality of clients is
A shared file management system further comprising communication means for communicating with the one client that is editing the shared file among the plurality of clients via the network. In the shared file management system according to claim 1 or 2,
An editing start request from another client for the shared file in the locked state is received in advance, and when the shared file becomes unlocked in the state control means, the shared file is set to the locked state and shared only to the other clients. A shared file management system, further comprising reservation means for editing a file. The shared file management system according to any one of claims 1 to 3,
A shared file management system, further comprising: forcibly terminating means for forcibly setting the shared file in the unlocked state when an elapsed time since the shared file is set in the locked state reaches a threshold value. For a shared file that can be accessed by each of a plurality of clients via a network, only the one client can edit the shared file based on an edit start request or an edit end request of one of the plurality of clients. A state control step for setting the locked state or the unlocked state in which the locked state is released;
Storing in the storage means state information including at least whether the shared file is in the locked state or the unlocked state;
Causing each of the plurality of clients to output status information of the shared file stored in the storage means, and
The state control step includes
After the editing end request is made from the one client, the shared file is unlocked when the editing start request is not made from the one client until a predetermined time elapses after the editing end request is made. And a shared file management system control method, wherein the shared file is locked when the editing start request is made from the one client . For a shared file that can be accessed by each of a plurality of clients via a network, only the one client can edit the shared file based on an edit start request or an edit end request of one of the plurality of clients. A state control function for setting the locked state or the unlocked state in which the locked state is released;
A function for storing in the storage means state information including at least whether the shared file is in the locked state or the unlocked state;
Causing the computer to realize a function of outputting status information of the shared file stored in the storage means to each of the plurality of clients ;
The state control function is
After the editing end request is made from the one client, the shared file is unlocked when the editing start request is not made from the one client until a predetermined time elapses after the editing end request is made. A program that sets the shared file in a locked state when the editing start request is made from the one client .

Images