>I have a simple address book client server application i'm working on.
>
>The application is a manual export from a mission critical application they use to store all adresses and contact information. The clients are read only by requirement as the employees only need to view the addresses not to change them.
>
>Currently I have about 5 clients that use the database 'shared' with localViews (stored in central location) and one db client that is the import master used to import once or twice a week when new clients are added to their other propriatery program. There needs to be a clearing of the current data and then a import from a flat file. Need to do it this way because no keys are exported(to keep track of specific records) and changes to data from propriatary program are often make(so can't just look for new records)
>
>My problem is such. If all readonly clients are closed the import works fine. When a client is open I need a way to either disconnect the client (so i can get exclusive access to table) or notify the person running the import that a client is open and should be shut down. Any other ideas on how to deal with this situation(Remote Views Etc., SQL Passthrough?) would be greatly appriciated. I've also concidered a login table but would perfer to avoid a situation like (computer crashes login not removed false table open errors). I've also concidered deleting records WO packing and re-adding during import, but eventually they will still need to pack the table and I will have to handle the same situation anyways.

A couple of approaches:

1. Have 2 separate copies of your program in 2 different folders. Use a launcher program to start the right one. For example, suppose Copy A is current. Users run the launcher program; it reads an .INI file and from that knows to run Copy A of your program.

In the meantime, it's time to do another update. You update Copy B, which will always work because no-one else is using it. You then modify the .INI file so users will now be using Copy B the next time they start the program.

The next time you update, you update Copy A.

The downside to this approach is that it isn't immediate - you can do an update but until a given user exits the program then restarts it, they're still working off the old data.

2. You could put a timer in your application that runs all the time and regularly checks (say once a minute) for the existence of a file in a given folder. If it exists, it means that you are about to do an update. In that case the timer event could pop up a messagebox to that effect.

Downside to this method is it's still subject to "lunch lock" if a user is away from her desk. You could escalate the action taken to actually shut the app down but that could be considered severe if the user was in the middle of inputting new data.