Is jumping across servers necessarily a bad programming practice?

I have a system created that a user at one of our other locations and on their server inserts a record. That data is then replicated to a central server. Users working on the central server are allowed to edit that record which means I have to lock the editing capabilities at the location the record was created.

However, i would like the creator of the record to be able to edit it so I am thinking about redirecting them across servers to edit the record on the central server. IS that bad practice and why??

The reason I only allow editing on one of the copies of the record is to prevent it from being copied over in replication.....

WE are also considering Bi-directional replication.

From stackoverflow

• In a past job life we used SQL Server transactional replication from a central publisher to three subscriber servers. Latency was such that the users clamored for (and received) the ability to update replicated data on the destination servers which resulted in replication failures/conflicts.

  It sounds like the overall design to use replication perhaps had not taken into account a desire (or need) to update the subscriber directly. Is is possible to do a quick white board with key players on this?

  Eric : @jl The design is fine because we are able to use bi-directional replication where the record can be updated on both sides. But a colleague of mine would rather redirect to the central server.