ToolBars and … (Access 2002)

Topic

New Reply

Hi everyone….

2 simple questions for the pros in here.

I am wrapping up a project. I am going to make this a replicated db as, as time goes on changes and additions will be made to the db.

Question 1. Can the Master be worked on while a user is inputing data in the replica?

Before I make this a replica, I want to do away with as many tool and menu bars as possible. I don’t want this to disturb the Master (when the master is updated, it will need the toolbars).

Question 2. How can I accomplish this?

On behalf of all the ppl who have received help and never said thanks, “THANKS”!! To ALL of you !!!….You people are GREAT…without you, I would be Poor and .

ps…did I mention I would also be institutionalized for the TOTALLY insane…they would have found me looking like this………

Thanks again.

Reply | Quote

Replies

Here are a few things to watch out for with replication.

1. Maintain the design master and at least one replica created from the design master as the top 2 levels. I usually refer to the 1st generation replica as the “hub” replica, and that’s the one I use to create all the replicas that people actually use. That gives you a fall back position when either the hub or the design master goes bad (notice I said “when”, not “if”).

2. You can work on the design master, but do *not* make changes to both design and to data in the design master. If you want to change data from the design master, sync any design changes first, then go back and make the data changes, get everyone out of the replicas, and sync them. In general, make data changes from a replica. You will get ugly conflicts if you try to mix design and data changes.

With a three-tier design, your replicas sync to the “hub”, and only the hub syncs to the design master, and then only when *you* choose. That means you can work on the design master while the replicas are syncing to the hub.

Reply | Quote

Another gottcha that you may run into is that of whether or not to split your database into a Front End (all objects except tables) and a Back End (tables only). In some respects it will make your replicated life easier, but there are some issues to consider. One in particular is whether both databases need to be replicated – I assume you are using Jet data files and not ADPs.

1 – Design changes to objects that are not local can only be made at the design master – in general that’s all of the forms, reports and modules.

2 – The same is true of design changes to tables – they must be made from the design master – but data can in general be made from anywhere.

3 – Table design gets a bit more complicated as you can’t normally use Autonumber fields as your primary key, you don’t really want to use the GUIDs that Access assigns, as performance suffers, and we’ve seen some strange behavior at times with joins, though not with 2002 (haven’t tried replication with it yet).

4 – Replication will bloat your database by at least 50% in most cases.

All these things really make sense in general, as you don’t want your users making design changes, though there are times when they might be wanting to do ad-hoc queries (if they are Access savy). In that case they can create local objects and use them. Bottom line – if you can solve your problem in a fairly straightforward manner without using replication, do so. It does add overhead, but it also solves some problems that can’t be addresses in any other fashion.

Best of Luck
Wendell Bell

Reply | Quote