Split and Replicate

[bbulla]

Hi,

I have a database that I have successfully replicated. It includes forms, queries and tables. Synchronizing works and all is good, but.....from what I keep reading on this forum, this is not the proper way to do it. It sounds like what I should be doing is splitting my database before replicating, and then just replicating the back-end.

When I do this, I find that when using the forms, etc. in the front end, I am unable to synchronize to the back end. I don't even have the option to do it through the menu options.

How do I make the front end recognize that the backend is replicated??

 

[GohDiamond]

If you are sharing the database on a LAN with a central server/shared storage then yes split the database first. That way you have a common backend that everyone will enter data into. Save the backend to a shared directory on the server or storage. Replicate the front end and put a replica on each desktop connected to the LAN.

Splitting the database will create a front end with the backend tables linked to the front end.
Replicating the front end will then make a Design Master and a Replica.
The Replica will show the symbol for all the replicated items as will the Design Master.
A new form or query or report added to the Design Master can be made replicable by setting the properties for that object, if it's not automatically set to replicate.

No changes can be made to the Replica only to the Design Master.
When the Design Master is changed and the Replica is synchronized to it each replica will pick up the changes made in the Design Master and all Replicas will work the same.

Be sure to backup the Design Master before making any changes.

There is the possibility of the Design Master becoming corrupted, but then there is an equal chance of the entire database becoming corrupted, we just have to live with that, so be ready to restore a working Design Master at all times.
The Design Master can be backed up the same way a database can be backed up.
Restoring a Design Master is as simple as taking the DM backup and replacing the corrupted one in its folder with the same name. (That's not the same as trying to use a Replica to replace the Design Master.)

I hope this gives you a direction to restart with.
Let us know if you have other questions. I have addressed many issues regarding replicated database in this forum before, so have a search.

Best Regards,
Goh

 

[bbulla]

OK, I think I follow. But...in my situation I have 4 tablet PCs that users are taking into the field in a 'disconnected' state, and using the database to collect data. So I think I need a backend on each tablet. Currently I am using a Design Master on a central server, and then 4 replicas. When the tablets come back online at the LAN, then they sync to the Design Master. I'm just testing this right now, and it seems to be working, but I just want to make sure I'm doing things right.

In this situation do I need to replicate the BackEnd AND the FrontEnd??

Also, I'm currently NOT splitting. I just took my original MDB and made a design master with replicas. Do I NEED to split??

 

[GohDiamond]

Without splitting you can certainly obtain the result you currently see. I haven't tried it this way but it makes sense that the replicas that are on the PC Tablets would synchronize to the Design Master even with the tables.

I'm only concerned that some information may not have a unique identifier if you are only using 1 field AutoNumbers. Also check that the external PC Tablet doesn't just pick up the Design Master data and dump the gathered data. (BACK UP THE External PC Replica before synchronizing)

I'm not sure but there may be a possibility for the autonumber from one tablet to overwrite data with the same autonumber already existing in the Design Masteror vice versa.

To avoid this problem use 2 autonumbers one sequential and one random as the primary key combination unless you are assigning your own code manually or programatically on each PC tablet.

You might want to test this theory by changing data in a record on 1 external PC tablet and see which way the data gets synchronized. Probably the external PC will update back to the Design Master data.

Let me us know what you find out.

Cheers,
Goh

 

[bbulla]

Well so far the AutoNumber has been working fine. I have never had any conflicts, and it seems like the chances are pretty slim. I agree, using 2 fields will lessen the chance of a conflict, but with the small amounts of data that are being entered I am not too concerned about that.

So, I am just using a Replicated database....no splitting, as it doesn't seem to make sense in my situation. One Design Master, and 4 replicas. Once the tablets come back online at the LAN, I synchronize them. So far, so good. We'll see what happens once the summer hits and we start collecting 'real' data.

 

[dfenton]

The advice given above is TERRIBLE. Replicating front ends DOES NOT WORK. Jet Replication is fine for pure Jet objects (tables and queries), but for Access objects, especially ones with code modules, it is disastrous in the long run. Remember that since the introduction of Jet 4 with Access 2000, the entire Access project is stored in a single BLOB field in one record of one of the system tables (instead of with each individual object having its own record in a system table). Why is this a problem? Well, it's because Access saves certain properties of forms and reports even in replicas (e.g., filter/sort), and that can lead to phantom conflicts between your front ends.

Those who've tried it have regreted it in the end -- there are too many examples to count of people completely corrupting their front end to the point of losing the whole project and needing to start over from scratch.

In any event, there is really no need whatsoever to replicate a front end. When you make a change, you send out a new copy to the users, or use an updater utility like the one from Tony Toews:

http://www.granite.ab.ca/access/autofe.htm