Link Table and Replication (1 Viewer)
- Thread starter tbarkdull
- Start date
dfenton
AWF VIP
- Local time
- Today, 09:49
- Joined
- May 22, 2007
- Messages
- 469
Your first mistake is replicating a front end. Front ends should not be replicated, only back ends. I would guess that you've added the link in a replica instead of the Design Master, but it doesn't matter, as you shouldn't be replicating in the first place.
In short, you wouldn't run into this problem at all if your app were properly designed to begin with.
Last edited:
dfenton
AWF VIP
- Local time
- Today, 09:49
- Joined
- May 22, 2007
- Messages
- 469
You have two sentences there and I honestly don't understand what either of them refers to.
The first sentence refers to "web pages created linked to queries" and I don't know what that means at all. Are you saying that you have a replicated Jet back end that is used as a data store for a web page, and the queries in the back end are being used as the data sources for the web pages? Queries are fine for replication as they are pure Jet objects. It's forms/reports/macros/modules that are unsuitable for replication. So, if I'm understanding correctly, your strategy is just fine.
The second sentence -- "I cannot work in it when others are needing access" -- makes sense only if your users are connecting directly to the Design Master. One should never use the Design Master for production use. The DM is the only special replica in your replica set, and it should be protected from the dangers of daily use, squirrelled away somewhere safe and synched with the other replicas only when you need to propagate design changes, or regularly enough to keep it from expiring (the default retention period is 1000 days, so once a month is more than enough).
I have never had users using any of the queries I keep in any of my back-end replicas, so I'm not sure what would happen if you synched a change from the Design Master to the production replica when a user had an object open in that replica. Theoretically, there should be no write lock on an open query, so it oughtn't be a problem. Changes to tables is much more complicated, though.
In short, your application should be using a different replica simply to protect the DM. That should allow you to make changes and synch them when the objects being changed are not locked.
But, again, I'm only guessing as to what exactly you mean, so I could be completely off base in everything I've written!
dfenton
AWF VIP
- Local time
- Today, 09:49
- Joined
- May 22, 2007
- Messages
- 469
If I'm remembering your screenshot correctly, the linked table is an ODBC link. I just tested and when I create an ODBC linked table, it, too, lacks a REPLICABLE property.
I just ran some tests and it doesn't seem possible to add an ODBC linked table to a Design Master and make it replicable. The only way to make them replicable is to create them in a non-replicated database and then replicate it.
This is something of a surprise, as it's quite different from regular Jet linked tables. I'm not sure I can think of a reason why this should be.
And I don't know what workaround you can use.
If your replica is on the same network with your Design Master, I'd suggest you export new linked tables from the DM to the production replica. That might make replication irrelevant, but if replication can't propagate your new ODBC linked tables, then there's nothing much you can do about it.
Yes, this is are ODBC linked table(s). The work-around I have found is this. Backup the database first. Synchronize with replica and check the box making the Replica the New Design Master temporarily. Open the New Design Master, add the linked table making sure the name is identical. Synchronize again making the old Design Master the Design Master again. Now the linked table(s) is added to both.
