Split db: What is the best way to keep Front Ends current? 2

[newyorkny]

Morning, tippers!

We split our A2K database into Front-End/Back-end to minimize the corruption we had been experiencing.

Now we face the chore of keeping everyone's FE current. What is "Best Practice" for doing this?

We do not have the use of any fancy "push" software installation packages, AFAIK.

Many thanks! NY

 

[earthandfire]

In that situation I simply use a batch file which copies the current front end from the server to the local machine and then runs it.

As far as the user is concerned, its still just a double click on an icon, and you can display a message saying something like "checking for current version..." whilst the copying is taking place.

 

[FancyPrairie]

I created a table that includes (among other things):

1. Computer Name (string)
2. Database Name (string)
3. Primary User's Name (string)
4. Primary User's Phone Number (string)
5. Primary User's Office Location (string)
6. New Version Flag (yes/no)
7. Broadcast Message Flag (yes/no)
8. Shutdown flag (yes/no)

You may think this is overkill but it really comes in handy as you add more users and create more databases. And, if you are going to create a table to handle this, it doesn't take anymore time to add these additional fields to the table. I would suggest putting the code and required forms in a library database so this method can be used on all future databases you create.

Create a shortcut to a batch job that launches your database (I use vbscript for this). The first think the job does is to determine the name of the computer. It then attempts to find the record that contains that computer name to see if the New Version flag is set. If the New Version flag is set, then copy the new version of the database to the user's machine and clear the flag. (Note that I have another table that documents each of my databases, including what folder they reside on the user's machine...but you can get by without that). If the computer has not yet been "registered" (i.e. doesn't yet exist in the table), then display a form from your library to register the computer. At the least you will want to know who the primary user is, their phone number and office location (in case you need to contact them).

At startup, I launch a form (invisible) that runs on a timer. And every minute it checks to see if a message is to be broadcast to the user's machine and/or if it should exit their database. There are times when, for whatever reason, I need users to exit out of the database. If the broadcast message flag is set, the OnTimer event will popup a form containg the message (i.e. "A new version exists" or "Please exit out of the database so maintenence can be done" or "Whatever"). After the user reads the message, the broadcast flag is cleared. If the user fails to exit out of the database, then set the Shutdown flag. The OnTimer event will then perform an Application.Exit command.

Now you have a record of who is using your database and what systems it's installed on. And, rather then distributing the new version to everyone, you can specify who gets it. For example, you might want just a few people to get the new version so that they can test it prior to releasing it to everyone.

 

[newyorkny]

Wow -- now I know why they call you "fancy!"

Those were both great thoughts.

Thanks and stars to both tippers.

NY

 

[dpk136]

I don't know your situation, but if you have a lot of users, but only a few of them will be on at a time, it might just be easier to put the front end in a shared folder on the server.

David Kuhn
------------------

http://www.davidpkuhn.com

 

[FancyPrairie]

I wouldn't recommend putting the FE on a shared folder. If one user corrupts the db, everyone is out of luck. Also, painting the screens, etc it much faster locally than over the network. Also, Mircrosoft recommends putting the FE on the user's machine for these reasons.

 

[earthandfire]

Based on personal experience, I agree 100% with FancyPrairie as far as location of Front End is concerned. Never run it from the server. Its just not worth the hassle.

 

[MichaelRed]

There are numerous other versions on the theme in these (Tek-Tips) fora. To find more information on this and / or other topics, I suggest that you learn to use the Search feature and exercise that knowledge regularly. Fancy prarie has posted the above in various levels of detail over several years. Generally, the level of detail decreases over time. I believe that in the near future, her advice on the topic will approach mine. To wit: look first.




MichaelRed

 

[Aqif]

I work in Maintaining almost a dozen database and I release updates all the times.

What I have done is

1. Create a seperate database (like a switchboard) with table containing fields for Database name, Current Version, Date Changed, Location of front-end file.
2. Created a temporary table in every frontend with fields LocalVersion and Date Changed.

How it works.

1. All of the users open the switchboard database and the startup form shows navigation to all the databases.
2. Compared with thier local local frontend version, the switchboard indicates whether they need update or not.
3. Use FileSystem object to copy the new frontend file from a predefined location.

I can explain more detail if anyone interested.


Cheers!
ÙÇãá

It's important to learn the rules so that you know how to break them.