Replication (Acess2000)

Topic

New Reply

Is it possible to use replication to keep forms, queries, reports, and modules updated? And if so, to what extent? For example, does it extend down to individual objects on a Form? For example, suppose2 people made changes to a form (let’s say each changed the location of a different control); would the 2 forms then be “synched”?

Reply | Quote

Replies

Hi Mark,
The general concensus is that using replication to distribute design changes is not the best strategy in most situations. The preferred approach seems to be a split database where the front-end is updated to individual workstations via the LAN, email, or sneaker-net, and to replicate only the data or back-end part of the application. A couple of resources that you might want to look at in detail are ACC2000: Microsoft Access 2000 Replication FAQ Available in Download Center and ACC2000: Jet 4.0 Replication White Papers Available in MSDN Online Library. Both seem to suggest that if you do take that approach, then you should distribute your design changes from the design master, but warn that there are reports of replicas not being fully updated after being synchronized. In addition, a form, query or report is considered to be an object from a replication perspective, so if two user changed the same query or report, you would get a replication conflict. You might also want to look at Trigeminal Software’s website as they have a number of resources related to replication.

We use replication only occasionally, and nearly always in what I call an occasionally connected network. If people want to be able to make their own queries and reports, we have them use a separate database from the application that we create, and we update the application on each user’s hard drive when we make a design change. Hope this helps to put things in perspective – perhaps others can share different experiences.

Reply | Quote

Wendell,

Thanks for the links. This is a situation I may or may not become involved with. To not split the databases and rely on replication to update the objects is already a warning flag for me. This will force customers to transmit their entire databases back to a central site to be updated! Seems like a ridiculous use of time. So I’m wondering what other nonsense I might have to put up with. I hate to forego a possible new source of income, but I’ve also come to realize in my old age that often money doesn’t make up for aggravation!

Reply | Quote

I agree that the situation looks pretty suspect. There are times when you just need to say “Hey, I’m the expert here and if you don’t want to heed my advice, then I don’t need your business!” There’s the old saw that says the customer is always right, but at the same time you have a moral responsibility to give them the best advice that you can.

Reply | Quote

Tough decision. My gut is telling me don’t do it. But VISA, MasterCard, Bank Of America, and a few others disagree!

Reply | Quote

Tough decision. My gut is telling me don’t do it. But VISA, MasterCard, Bank Of America, and a few others disagree!

Reply | Quote

I agree that the situation looks pretty suspect. There are times when you just need to say “Hey, I’m the expert here and if you don’t want to heed my advice, then I don’t need your business!” There’s the old saw that says the customer is always right, but at the same time you have a moral responsibility to give them the best advice that you can.

Reply | Quote

Wendell,

Thanks for the links. This is a situation I may or may not become involved with. To not split the databases and rely on replication to update the objects is already a warning flag for me. This will force customers to transmit their entire databases back to a central site to be updated! Seems like a ridiculous use of time. So I’m wondering what other nonsense I might have to put up with. I hate to forego a possible new source of income, but I’ve also come to realize in my old age that often money doesn’t make up for aggravation!

Reply | Quote

Hi Mark,
The general concensus is that using replication to distribute design changes is not the best strategy in most situations. The preferred approach seems to be a split database where the front-end is updated to individual workstations via the LAN, email, or sneaker-net, and to replicate only the data or back-end part of the application. A couple of resources that you might want to look at in detail are ACC2000: Microsoft Access 2000 Replication FAQ Available in Download Center and ACC2000: Jet 4.0 Replication White Papers Available in MSDN Online Library. Both seem to suggest that if you do take that approach, then you should distribute your design changes from the design master, but warn that there are reports of replicas not being fully updated after being synchronized. In addition, a form, query or report is considered to be an object from a replication perspective, so if two user changed the same query or report, you would get a replication conflict. You might also want to look at Trigeminal Software’s website as they have a number of resources related to replication.

We use replication only occasionally, and nearly always in what I call an occasionally connected network. If people want to be able to make their own queries and reports, we have them use a separate database from the application that we create, and we update the application on each user’s hard drive when we make a design change. Hope this helps to put things in perspective – perhaps others can share different experiences.

Reply | Quote