Reasonable time between updating front ends

[Lightwave]

Just a general query.

I've built my first database for a sepearate organisation. Project Management database that manages planning applications and I'm wondering how often I should leave it between updates of the front end.

Its annoying to see mistakes in the front end and which are there through oversight. However realistically speaking many are quite minor and the users probably haven't even noticed.

I am aware that the users are very much in the first stage of getting use to the database and may not react well to frequent changes.

For those that have experience.
How often do you update front ends after initial install?
In your opinion is there a good balance period between updated if so what is it?

Mark

 

[Mr. B]

The timing and number of updates should be based on the "Need" and not on any kind of time frame.

If you have an issue of any kind that presents the "need" for an update, by all means, provide the update.

 

[gemma-the-husky]

regularly

there is often a need to update for

bugs/errors/corrections

and a need to update for

changes/improvements/modifications

these need doing as quickly as possible, i would have thought

 

[AlienRay]

I've started using database Replication to keep my users' Front Ends up to date at all times. In most cases, I've found that users don't even notice their modules have been updated unless I tell them.

 

[boblarson]

I've started using database Replication to keep my users' Front Ends up to date at all times. In most cases, I've found that users don't even notice their modules have been updated unless I tell them.

OUCH!! Bad thing. Replication should ONLY be used with Tables (and maybe queries). You do NOT want to use replication for forms, reports, macros, and code. You WILL suffer for it eventually - that is pretty much a guarantee.

 

[The_Doc_Man]

I work on monthly cycles for anything that is NOT a show-stopper, but within a couple of days of discovery/resolution for show-stoppers.

I find that after about 6 months on a new major release, most of the crud has shaken out of the woodwork and the monthly update can become quarterly.

 

[Banana]

To my mind, the "timeframe" between front-end updates should not matter at all. Users like having their bugs fixed quickly and won't mind as much if there is a good front-end updater in place to automate the updating and it's even better if it's done without their active intervention (e.g. they don't have to go to a site and download the new version - it does all that by itself on say, closing the application for example).

This way, it's now easy to fix the bugs even if they're just little annoying bugs quickly and have users not wait a month or so to get that one annoying bug fixed. Of course, caution is required in ensuring that front-ends are versioned and thus can be rollbacked or even better, tested adequately.

 

[dfenton]

I've started using database Replication to keep my users' Front Ends up to date at all times. In most cases, I've found that users don't even notice their modules have been updated unless I tell them.

In addition to Bob Larson's comment about the danger of losing your project from replicating your front end, let me add that if you give any thought at all to what replication is about, you'll realize that you *don't* want to use it to push out front-end databases.

Replication is a two-way operation. It's based on the idea that after a synch, the two replicas that were synched will be identical.

But for front ends, there is nothing in the user front ends that you need to synchronize. Indeed, there are actually changes made to front ends (e.g., saved filters/sorts in forms), and so there is something that will be synched back to your development replica. But it's not something you *want* to be synched, as you don't care about your users' filter/sorts (and other properties that get saved).

If different users' front ends have updates to those properties, you'll end up with conflicts, but those conflicts are not necessary at all.

The only scenario in which replication of your application objects solves a real problem is when you've failed to split your app. In that case, splitting solves the problem much better than replication, and removes a whole host of other dangers, as well.

Jet replication is for synchronizing data tables, period, end of statement.

It should not be used for any other purpose.

 

[Lightwave]

Thanks everyone wil bear these points in mind

 

[AlienRay]

Replication is a two-way operation. It's based on the idea that after a synch, the two replicas that were synched will be identical.

Perhaps that's the intention, but it's very easy to implement one-way replication.

Here's my method. I have a Design Master stored on my personal server. I also have a "master" Replica stored on a shared group server. Finally, all of my users have their own personal Replicas stored on their personal drives. I also have a shared table that stores the date of the last module upgrade.

Obviously, all development is done in the Design Master. When it's time to deploy a new version of the user module, I simply Synchronize the Design Master with the master Replica, then change the date in the Version List to indicate a new version is available.

When a user launches his copy of the module, the first thing that happens is the application compares the date of his personal copy to the newest version date. If there's a difference, then it does a one-way sync, from the master Replica to the personal Replica. The personal Replica is then date-stamped to ensure it doesn't try to synchronize again before a new version is ready.

I've been using this method for a few years now, and in my experience, the synchronization has always worked flawlessly. There's also very little danger, since I keep regular backups of all my Design Masters. Even if everything were to explode for some reason, the form and report structures are safe.

 

[dfenton]

Yes, of course it's possible to do one-way synchs, but that's not what replication is designed for. In a split application (the only kind there should ever be), you push out updates by replacing the existing front end with a new front end -- no need for replication. In an unsplit app, you've made a design error by not splitting.

Replicating front ends is just a complete error. It is bound to fail eventually because Jet doesn't understand the internal structure of the single BLOB field in which the whole Access project is stored. The dangers are so great, even with one-way synchs, that it just isn't worth it, particularly, given that it's not even necessary, unless you've made the stupid mistake of not splitting your app.

And, yes, I consider it STUPID to not split an Access app, unless it's done in ignorance.

 

[AlienRay]

It is bound to fail eventually

Two years so far and still going strong. I'll tell you what: when the application finally does blow up, and all the armies of the apocalypse descend upon me, I'll be sure to let you know. If nothing else, it'll produce some valuable field data.

 

[dfenton]

Two years so far and still going strong. I'll tell you what: when the application finally does blow up, and all the armies of the apocalypse descend upon me, I'll be sure to let you know. If nothing else, it'll produce some valuable field data.

It's completely idiotic to do something you know is going to fail at some point when it's so incredibly easy to avoid the issue. Indeed, it's *much* easier to not use replication for distributing front end changes, since you don't have to use code to distribute your changes (which you must do if you want to use a one-way synch).

I hope you're not being paid by a client for this work, because if you are, you deserve to be sued for everything you're worth when it finally goes South.

 

[AlienRay]

The goal here is to update the users' Front-End modules automatically, without requiring any action on their parts. The two ways I usually accomplish this is either by replication, or by physically overwriting their personal copies of the Front-End file. As far as I know, both methods are going to require code to trigger them. I've used both methods without any trouble, but if you know a way this can be accomplished without the use of code, I'd love to hear about it.

 

[dfenton]

The goal here is to update the users' Front-End modules automatically, without requiring any action on their parts. The two ways I usually accomplish this is either by replication, or by physically overwriting their personal copies of the Front-End file. As far as I know, both methods are going to require code to trigger them. I've used both methods without any trouble, but if you know a way this can be accomplished without the use of code, I'd love to hear about it.

There are plenty of methods that require no code. Here's one that is incredibly good:

http://www.autofeupdater.com/

Or you could write batch files to do the job, of vbScript, but of course, those would be executing code, just not as part of your app.

Replication is simply not a viable method of doing this, and it never was.

 

[c_smithwick]

Improvements and additional functionality should be implemented as soon as they are developed and FULLY bug tested. As to bugs, I use line numbers on all my code and keep a duplicate "development" database on my local hard drive. My error handling is set up within my deployed database to send me an email with the error, line number and function where it occurred whenever an error is thrown, that way I can fix all "bugs" as they occur. In my opinion, a release with a bunch of bugs reflects rushed programming and sloppy coding. I know this is a generality and not always the case, but the exceptions are few.