We have a database which has been created by an external developer. We are now in the process of putting in a few additions, but i go to the master database and the tables show a little logo with a red and green circular arrows and the property shows "Table (Replicated)". This means i'm unable to edit the table properties.
Does anyone know how i can find out where it is replicated from / how to get around this or explain how this function is acutally used / useful?
Is your application split, or is there a single omnibus MDB with both tables and forms and reports and so forth? If it's a single file, then your developer may be using replication to push changes to the application part of your MDB without causing problems with the data.
This is something that is a bad idea for several reasons:
1. the app should be split, no ifs, ands or buts. The tables should be in a separate shared back end MDB, and everything else in a front end MDB that has linked tables that point to the shared back end. All users should have a copy of this front end on their computers, one per each workstation.
2. once the app is split, there's no reason to replicate the front end, as all you need to do to update the front end application is to replace it with the new copy.
3. Jet replication works completely reliably for pure Jet objects (it is a Jet technology), i.e., tables and queries, but works poorly on Access objects (forms, reports, modules). This is because of the way the Access project is stored, as a single BLOB field in a single record in a system table. The structure of that field internally is quite complex, and changes made to it at multiple front ends eventually will end up corrupting the Access project. This can lead to loss of the entire replica set. Given that there's no justification for replicating front-end objects in the first place, it's particularly stupid when someone does it. If that is the case, then you have a developer who is either incompetent or who is being paid for work that is well beyond his demonstrated level of expertise.
If it's split, then that means the back end is replicated. In that case, you may or may not need replication. Do you have laptop users who synchronize their data when they return to the office? If so, you need replication, and it's a very good technology for that task.
If not, it's not clear why it's replicated at all.
But you can't unilaterally unreplicate or promote your replica to Design Master status, because this would completely break the relationship with the developer's files. You need to consult with the developer on this.
You should tell him/her that if the app needs replication, then the Design Master MUST be on your server, not on his computer. It is your database and not his, and you need to have control of all the assets. I have been developing replicated Access apps since 1997, and for every single one of them, the DM is on the client's PC/server. Most of my clients provide me remote access so that I can work with their DM and apply changes to the structure. However, in a completed application in production use, design changes should be very, very rare, particularly because they can be extremely dangerous (unless they are trivial, such as just adding a few new fields).
Temporarily, you could create a new table linked 1:1 to the table you want to add the fields to and then join that in the recordsources of your forms/reports where the table you want to alter is used. I do this in my working copies of replicated apps when I can't alter the DM, and sometimes it lasts longer than I intend. But it is at least a temporary way to start storing the data. Be advised, though, that it can cause some issues in terms of display of data, and you'll want to be sure you use an outer join, so that the main table displays even when there's no corresponding record in the other table.
