 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / June 2006Synchronization History AWOL
Hi Firstly - what a relief to find an Access Community with a dedicated Replication area. I've found it increasingly difficult to find the similar area on the Microsoft site. Here's my question - it would be great to get an answer because I can't work out what the problem is...... I've set up Indirect Scheduled synchs which seem to be working fine. ReplMan is on both client and server. Synch details are listed fine in both the client and server log files. However, when trying to view synch details using 'View Synchronization HIstory' in Replication Manager details only appear on the client machine and not when I am at the server. Is this normal or have I set something up wrong? I would have thought, since the indirect synchs are scheduled FROM the Server Synchronizer, the details would have been visible from there as well? Thanks for any help Nigel > I've set up Indirect Scheduled synchs which seem to be working > fine. ReplMan is on both client and server. Synch details are > listed fine in both the client and server log files. However, when > trying to view synch details using 'View Synchronization HIstory' > in Replication Manager details only appear on the client machine > and not when I am at the server. The history you see will be the history for the replica you have open. If you open a managed replica, you should see the history of the synchs with the other synchronizer. > Is this normal or have I set something up wrong? I would have > thought, since the indirect synchs are > scheduled FROM the Server Synchronizer, the details would have > been visible from there as well? The history displayed by ReplMan is the data from the exchange history table in whatever replica you have opened in ReplMan. Open a different replica and you will see a different history.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Glad to hear from you again - thanks for the reply. I think it underlines that I have a problem. I have two replicas, HubA and HubB, both managed by their own synchronizers. I'm testing at the moment and I've set regular automatic syncs, some initiated at the server (HubA), some at the client (HubB). All details are shown when I "View History" at the client but neither are shown at the server, despite the syncs being solely between these two replicas. The only details shown server-side are for manual indirect syncs I've initiated from there. Am I being stupid? I just thought that sync details between HubA and HubB would be viewable by ReplMan at both HubA and HubB? Cheers Nigel >> I've set up Indirect Scheduled synchs which seem to be working >> fine. ReplMan is on both client and server. Synch details are [quoted text clipped - 15 lines] >history table in whatever replica you have opened in ReplMan. Open a >different replica and you will see a different history. > Glad to hear from you again - thanks for the reply. I think it > underlines that I have a problem. [quoted text clipped - 11 lines] > Am I being stupid? I just thought that sync details between HubA > and HubB would be viewable by ReplMan at both HubA and HubB? Do you have any other replicas managed by the synchronizer at HubB? That is, could you perhaps be synching with a different replica than you think? If there's only one managed replica at HubB, I don't know what the problem would be. Is the data going through? Have you looked at the history system table directly? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Thanks for the reply. I'm away for the next few days so will do some checking on my return. Thanks Nigel >> Glad to hear from you again - thanks for the reply. I think it >> underlines that I have a problem. [quoted text clipped - 9 lines] >problem would be. Is the data going through? Have you looked at the >history system table directly? Hi David You are a genius! Thanks for the help. I've just recreated the hub replicas on the server and client and both are working fine with full synch histories at both sites. I think the problem may have been my attempt at a replica farm. I had set up the replica farm and it's synch schedule before doing the remote client hub. I may have been synching with one of the replica farm reps rather than the server hub. Thanks once again Nigel >Hi David > [quoted text clipped - 11 lines] >>problem would be. Is the data going through? Have you looked at the >>history system table directly? Hi David Sorry to reply to my own email - I'm not lonely, honest. I've just created a replica farm and things are going fine so far. Just a couple of questions I'd be grateful for an answer on.... 1 I wonder if the previous problem was caused by me setting up the replica farm first - so when synchs occurred the Synchronizer looked for any replica to synch the client with, whereas now, after first setting up the synch from ServerHub to Client the Synchronizer always synchs with SERVER_HUB.mdb? 2 Is it the same synchronzier that does both internal (SERVER_HUB to SERVER_REPS) and external (SERVER_HUB on server to SERVER_HUB on client) synchs. 3 Does it matter if you have local scheduled synchs between SERVER_HUB.mdb and SERVER_REPS.mdb occurring at the same time period as synchs between the Server and Client machines. 4 Are local synchs direct and can they be made indirect. 5 Would you advise the use of a LAN replica as well as a HUB replica or just let LAN users connect directly to the HUB? Best Wishes Nigel >Hi David > [quoted text clipped - 16 lines] >>>problem would be. Is the data going through? Have you looked at the >>>history system table directly? > Sorry to reply to my own email - I'm not lonely, honest. I've just > created a replica farm and things are going fine so far. [quoted text clipped - 7 lines] > after first setting up the synch from ServerHub to Client the > Synchronizer always synchs with SERVER_HUB.mdb? I wouldn't manage the edited replica. But I would put it on a schedule. That would mean that the edited replica would synch with one of the replicas in the replica farm, and should be choosing the same replica that remote replicas are synching with. Even if they don't, two synchs should get all new data through, as long as the replica farm is on a synch schedule whose interval is less than or equal to the synch interval between the edited replica and the farm. > 2 > Is it the same synchronzier that does both internal (SERVER_HUB to > SERVER_REPS) and external (SERVER_HUB on server to SERVER_HUB on > client) synchs. There can be only one synchronizer per machine. > 3 > Does it matter if you have local scheduled synchs between > SERVER_HUB.mdb and SERVER_REPS.mdb occurring at the same time > period as synchs between the Server and Client machines. Direct or indirect, I can't see that it would matter. I would always do direct synchs over a LAN connection, no matter if I had the indirect option or not. > 4 > Are local synchs direct and can they be made indirect. Not sure what you mean here. Do you mean the synchs between the replicas in the server farm, or the synchs between replicas on stored on the same file server? Those should all be direct, in preference to indirect, simply because direct is more reliable (many of the conditions that can cause an indirect synch to fail with a mystifying error would cause a direct synch to fail unconditionally). > 5 > Would you advise the use of a LAN replica as well as a HUB replica > or just let LAN users connect directly to the HUB? I'd never have the LAN users editing the hub. Indeed, you *can't* do that, as if you do, then the remote users will do a direct synch and not indirect, since the replica that LAN users edit has to be in a public share. Any replica that is in a public share can't reliably be forced to synch indirect. The minimum replica configuration for indirect synch with LAN editing is: REMOTE MACHINE: - Edited replica SERVER - Hub replica - Production replica for LAN users I would say that any situation where there is more than one user editing simultaneously should not be happening in a replica that is serving as a synch hub (with scheduled synchs). The reason is that having multiple users editing the hub replica increases the chance of edits being in process while a synch occurs, which can cause the synch to fail. It can also corrupt memo fields if they are being edited in bound forms. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Thanks for the reply again. 1 You said you wouldn't manage the edited replica but that you would put it on a schedule. How do you schedule a synch with a replica which is not in a Synchronizers list of managed replicas? 2 A couple of weeks ago I wrote about scheduled synchs appearing in the Synchronization History of a Client but not the Server. I now know why this happened. The server Synchronization History shows synchs between the Server HUB.mdb and the Client Synchronizer. Everything was fine until I added REP1. At that point the client started synching with REP1.mdb instead of HUB (I presume the Server Synchronizer decides which of the managed replicas in a farm gets synched) so there were no synchs with HUB.mdb so no items were added to the list. The Client's Synchronization History shows synchs between the Client HUB.mdb and the Server's Synchronizer. This will always add an item to the client log since there is no replica farm on the client so there are no alternative mdbs for the Client Synchronizer to choose. My question here is really if I have set the replica farm up correctly. I created replicas in Replication Manager by selecting File > New Replica and put them in their own folder. They, along with the HUB.mdb and LAN.mdb, are all listed under the Server Synchronizer list of managed replicas. The Server Synchronizer has the caption SERVER (4) depicting the 4 managed replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be set up? Many regards David for any help Nigel > 1 > You said you wouldn't manage the edited replica but that you would > put it on a schedule. > How do you schedule a synch with a replica which is not in a > Synchronizers list of managed replicas? The partner replica has to be managed. That is, a managed replica can synch on a schedule with an unmanaged replica. This is the only way I've ever set up my replica sets, with the production replica unmanaged and the hub synch replica managed, with a scheduled synch between the two. > 2 > A couple of weeks ago I wrote about scheduled synchs appearing in [quoted text clipped - 6 lines] > farm gets synched) so there were no synchs with HUB.mdb so no > items were added to the list. Yes. There's a KB article about this, as well as an article on Michael Kaplan's website that explains how Jet chooses the replica to synch with. It really oughtn't be an issue, though. If you have mutliple managed replicas, you should schedule synchs between them so that they will have identical data after each round of synchs. That way it won't matter which replica is chosen for synchs with remote replicas. > The Client's Synchronization History shows synchs between the > Client HUB.mdb and the Server's Synchronizer. This will always add [quoted text clipped - 8 lines] > replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be > set up? With one exception -- I think you should schedule synchs between the members of your replica farm. I've never used replica farms per se. I've just kept a hub replica (managed) and a production replica (for editing) on each server. This is the smallest possible replica farm and doesn't really get you the full benefit of it (since if the hub replica goes bad, your external synchs fail), but it's been good enough for the situations I've had set up. However, I will note that I don't have any current clients using indirect scheduled synch at all. Indeed, I have only one, and that isn't on a schedule at all. This is because all my clients that need remote editing are now using Terminal Server and all my clients with laptops just use direct synchs when back in the office. I don't have any clients who need the indirect replication scenario, so don't use it any more. My last indirect replication project went offline a couple of years ago (after many years of successful operation in the setup I outlined above), and it was designed before Michael had developed the concept of the replica farm. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Thanks for the reply again. The Scheduled Synchs not appearing in the 'Synchronization History' of the Server is just a pain - it is not convenient to go to the Client to see when synchs with the Server occurred. I know I can view the Server log files but it is still inconvenient. There should be some GUI to view all synchs between all members of the Server replica set and themselves/remote Clients. Best Wishes Nigel >> 1 >> You said you wouldn't manage the edited replica but that you would [quoted text clipped - 49 lines] >setup I outlined above), and it was designed before Michael had >developed the concept of the replica farm. > The Scheduled Synchs not appearing in the 'Synchronization > History' of the Server is just a pain - it is not convenient to go > to the Client to see when synchs with the Server occurred. I know > I can view the Server log files but it is still inconvenient. > There should be some GUI to view all synchs between all members of > the Server replica set and themselves/remote Clients. I'm not sure I understand what the problem is. All synchs with a particular replica or with a particular synchronizer are viewable in the synchronization history of that particular replica. Now, it is the case that synchs do not produce symmetrical records in both partner replicas, so you don't know everything that happened in the remote replica, but it's enough to tell you when it happened and how it changed the replica you're viewing. Are you sure you're just not scrolling up the dropdown for the synchronization history choice for your synchronizer to see all synchs? Sounds to me like you need to spend some time investigating all the features of ReplMan. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Here's what I understand to be the problem. Suppose you have a replica farm with 3 managed replicas (A, B, C) all in the same replica set. Suppose they synchronize with a remote synchronizer called Sync2. Further suppose that you currently have B opened in the RM and are looking at the sync history, and it shows that *no* syncs have occurred with Sync2. What can you conclude?... nothing... You must open either A or C to ensure that you've looked for all the possible syncs that may have occurred. I think that's the problem you were referring to. AFAIK - each replica retains only the sync history between itself any any other replica. It does *not* retain the sync history between its "parent" farm and the other replicas. What's the solution? 1) Know which replica in the farm that Access uses for its "base replica", and always open it into RM. *That's* the one that will be used as the first choice when sync'ing. See http://support.microsoft.com/kb/q173002/ 2) (kludge) create a frontend that links to the replication history table in each replica in the replica farm and create a UNION query that displays all the synchronization history records. >Hi David > [quoted text clipped - 63 lines] >>setup I outlined above), and it was designed before Michael had >>developed the concept of the replica farm. **********************jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security > AFAIK - each replica retains only the sync history between itself > any any other replica. Not precisely correct: between that replica and any other replicas *or synchronizers*. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi Jack Thanks once again. My problem was exactly as you said. I was simply viewing the default ReplMan view of my topology. This used a managed replica which was not the base replica. Selecting File > Managed Replicas > basereplicaname.mdb loads the base replica's version of the ReplMan map which does have all the synch history information. Thanks again Nigel >Here's what I understand to be the problem. Suppose you have a replica >farm with 3 managed replicas (A, B, C) all in the same replica set. [quoted text clipped - 29 lines] >remove uppercase letters for true email >http://www.geocities.com/jacksonmacd/ for info on MS Access security Hi David Everything seems to be working fine now thanks. How do you allow your laptop users to synch back at the office. For example, do you use DAO such as db.synchronize or give them access to the Access UI? Nigel >> 1 >> You said you wouldn't manage the edited replica but that you would [quoted text clipped - 49 lines] >setup I outlined above), and it was designed before Michael had >developed the concept of the replica farm. > How do you allow your laptop users to synch back at the office. > For example, do you use DAO such as db.synchronize or give them > access to the Access UI? Depends on the users. I used to just have them use the Access UI, but that requires opening the back end, so lately I've been creating a UI for them that does all the work. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Just a couple of questions... 1 How do you allow your laptop users to perform the direct synch back in the office - do you use DAO (db.synchronize, etc) behind a command button or do you let them access the Access UI? 2 The synchronizer log file on both the client (a desktop pc acting as a server at a remote site) and server is recording attempts at synchs every minute! Is this normal? On the server I have set up a replica farm with managed hourly direct synchs, an unmanaged hourly direct synch to the LAN backend and a managed daily synch to the CLIENT hub. One possible cause of this could be that I've set up a task on the server which daily runs a batch file to load Mstran40.exe. This is to ensure the synchronizer is loaded whenver the server starts no matter what user id is used to start the server. Any help appreciated. With Replication I feel like Mulder - ever week I feel I've finally nailed the issue then, just as I almost congratulate myself, there's a whole new mystery which puts me back at square one again. Nigel > 1 How do you allow your laptop users to perform the direct synch > back in the office - do you use DAO (db.synchronize, etc) behind a > command button or do you let them access the Access UI? Answered in my other post. > 2 The synchronizer log file on both the client (a desktop pc > acting as a server at a remote site) and server is recording > attempts at synchs every minute! Is this normal? On the server I > have set up a replica farm with managed hourly direct synchs, an > unmanaged hourly direct synch to the LAN backend and a managed > daily synch to the CLIENT hub. I'm not sure. I've never seen that. I've also never set scheduled synchs at that short a period. > One possible cause of this could be that I've set up a task on the > server which daily runs a batch file to load Mstran40.exe. This is > to ensure the synchronizer is loaded whenver the server starts no > matter what user id is used to start the server. Hmm. All you really need to do is drop a shortcut to Mstran40.exe into the STARTUP folder of the ALL USERS profile under C:\Documents and Settings. Your batch file shouldn't have an effect on the synchs, as it can't initiate a new instance of the synchronizer if it's already running, and wouldn't be trying to do so, anyway, as it should be executing only on startup. Of course, you don't say exactly how you're running the batch file, so perhaps it is getting executed twice, or when the synchronizer is already running, but it shouldn't matter, in any case. That is, I don't think it's the cause of your log entries. > Any help appreciated. With Replication I feel like Mulder - ever > week I feel I've finally nailed the issue then, just as I almost > congratulate myself, there's a whole new mystery which puts me > back at square one again. We've all been there. It's not going to get better, either, as MS is basically abandoning Jet replication with the next version of Access. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David I've removed the replica farms and everything is synchronizing when it should. I didn't block-fill all the schedule blocks - I've no idea why it was synching every minute - it was only supposed to be doing it every hour. Anyway, it is working now. As regards the direct laptop sycnchs you do - have you had any problems direct synching with the live backend when other LAN users could be making live edits? Cheers Nigel >> 1 How do you allow your laptop users to perform the direct synch >> back in the office - do you use DAO (db.synchronize, etc) behind a [quoted text clipped - 37 lines] >basically abandoning Jet replication with the next version of >Access. > As regards the direct laptop sycnchs you do - have you had any > problems direct synching with the live backend when other LAN > users could be making live edits? Yes, for memo fields. Also when trying to synch design changes. For memo fields, make them unbound. This is easy by putting in the form's record source, and loading the data into an unbound textbox in the OnCurrent event of the form, and writing the value back to the recordsource in the AfterUpdate event of the unbound textbox. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David I've yet to make design changes and ripple them out to all the replicas. I thought you made the design change to the DesignMaster then synched them out to the replicas as soon as possible. If it is a small site I'd be tempted to simply recreate the replicas. Nigel >> As regards the direct laptop sycnchs you do - have you had any >> problems direct synching with the live backend when other LAN [quoted text clipped - 6 lines] >in the OnCurrent event of the form, and writing the value back to >the recordsource in the AfterUpdate event of the unbound textbox. > I've yet to make design changes and ripple them out to all the > replicas. I thought you made the design change to the DesignMaster > then synched them out to the replicas as soon as possible. Yes, but if that synch happens while a replica is being edited, the change won't be propagated, since structural changes to tables can't be applied while someone has the table open. It doesn't matter if the changes go direct from the DM to the replica, or through an intervening replica -- the result in a replica that is being edited at the time the synch of the design change is attempted will be a failure of the synch. > . . . If it is a small site I'd be tempted to > simply recreate the replicas. No, you can't ever do that because it creates dead replicas, which can lead to replication errors and possibly complete corruption and loss of the replica set. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David So if I make sure all users are off the system then there should be no problems with rippling out any DM changes? Nigel >> I've yet to make design changes and ripple them out to all the >> replicas. I thought you made the design change to the DesignMaster [quoted text clipped - 14 lines] >can lead to replication errors and possibly complete corruption and >loss of the replica set. > So if I make sure all users are off the system then there should > be no problems with rippling out any DM changes? As long as the changes are valid and don't involve any changes to validation rules or referential integrity that would prohibit them from being propagated. I always try to break down design changes that alter RI and validation rules into small steps with a synch between each steup, instead of doing them all at once and hoping Jet puts them through in the right order. It's the same any time you're doing something like changing the foreign key on child records. You want to change the foreign key, synch, then delete the parent record and synch again, rather than doing both, because if CASCADE DELETES is on, you run the risk of deleting the child records instead. In general, design changes should be avoided in a production app, unless absolutely necessary. What this means is that you have to settle the schema before the app goes into production, and if necessary schema changes become apparent later, you have to be very careful about rolling them out. The key is making plenty of backups of the affected data and doing your changes as incrementally as possible. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Thanks for the DM change advice. I've identified the cause of the 'Synch every minute despite not setting this option' problem. The SERVER_DROPBOX folder had slightly dodgy permissions and would not allow deletes. This seemed to be causing a massive build-up of temp files - over a thousand in a day - all with the prefix rep. For example, rep101.msg (4kb), rep101.mdb (168kb), rep101.ldb (4kb), rep101.tmp (0kb). The network administrator said this was due to permissions not filtering down properly. He manually set the permissions to Modify for all users and the problem was solved. A few questions: 1 As regards my suggestion to simply recreate the replicas when changing DM structure I meant deleting all replicas (from both the ReplMan map and the hard-drive) then creating new replicas using File > New Replica. The new replicas would have the same name but since the originals are no longer there is that a problem? 2 To roll out replicas to a remote office pc (which will act as the remote office server) I make a dos copy of HUB.mdb (also called HUB.mdb) and put it on the remote pc. I then open ReplMan and manage this copy. This gives the copy it's own id. I then synchronize with the SERVER so both synchronizers become aware of both replicas. Is this ok? I've read that both this method and using the ReplMan > File > More Replica are both fine. 3 To put a replica on a laptop I connect the laptop to the server, open the server's BE.mdb and then create a replica using the Access menus. Is this how you would do it? Thanks for the help. Have a nice weekend. Nigel >> So if I make sure all users are off the system then there should >> be no problems with rippling out any DM changes? [quoted text clipped - 19 lines] >of the affected data and doing your changes as incrementally as >possible. > 1 As regards my suggestion to simply recreate the replicas when > changing DM structure I meant deleting all replicas (from both the > ReplMan map and the hard-drive) then creating new replicas using > File > New Replica. The new replicas would have the same name but > since the originals are no longer there is that a problem? If you're keeping the same DM, then, yes, it would be a problem, since the DM still has a record of the replicas you created. I suggest you search the archives of this newsgroup on Google Groups for the phrase "dead replicas" because that will explain to you why this is a bad idea. Basically, once a replica is in place, it has to remain in that place and not be copied, moved, deleted, emailed or overwritten by a file of the same name. > 2 To roll out replicas to a remote office pc (which will act as > the remote office server) I make a dos copy of HUB.mdb (also [quoted text clipped - 3 lines] > both replicas. Is this ok? I've read that both this method and > using the ReplMan > File > More Replica are both fine. It's OK to use a copy of a replica to initialize a setup with the first replica. Once it's in place, then it has to stay there. > 3 To put a replica on a laptop I connect the laptop to the > server, open the server's BE.mdb and then create a replica using > the Access menus. Is this how you would do it? You could do that or copy it just like with the hub. But that is the only situation where a file system copy is OK, because it creates a new replica ID as soon as the file is opened in its new location. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks, once again, David for your help and advice. Nigel >> 1 As regards my suggestion to simply recreate the replicas when >> changing DM structure I meant deleting all replicas (from both the [quoted text clipped - 27 lines] >only situation where a file system copy is OK, because it creates a >new replica ID as soon as the file is opened in its new location. Hi David Two questions I'd appreciate your opinion on... 1 I copy the HUB replica into a folder on the server. I then copy this out to be the remote HUB. I appreciate that once the remote HUB is opened/initialized it can never be moved. However, why do you say the copy on the server must never be there? 2 Making a copy of the managed server HUB into the remote HUB on several pcs means each HUB has the same file name. Is this ok or would it be better for each remote HUB to have it's own name? Cheers Nigel >> 1 As regards my suggestion to simply recreate the replicas when >> changing DM structure I meant deleting all replicas (from both the [quoted text clipped - 27 lines] >only situation where a file system copy is OK, because it creates a >new replica ID as soon as the file is opened in its new location. > Two questions I'd appreciate your opinion on... > > 1 I copy the HUB replica into a folder on the server. I then copy > this out to be the remote HUB. I appreciate that once the remote > HUB is opened/initialized it can never be moved. However, why do > you say the copy on the server must never be there? Did I say that? I don't see that in anything I wrote. What is it that you're interpreting to mean that? > 2 Making a copy of the managed server HUB into the remote HUB on > several pcs means each HUB has the same file name. Is this ok or > would it be better for each remote HUB to have it's own name? I always make all the replicas have the same filename, but since the proper place to store user data is in the user's profile, they would not have the same *path*. And, given that each machine must have a different name, the machine name place the local path means that each is unique. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Regarding my question "However, why do you say the copy on the server must never be there?" and your response "Did I say that? I don't see that in anything I wrote. What is it that you're interpreting to mean that?". I was reading your first comment ("Basically, once a replica is in place, it has to remain in that place and not be copied, moved, deleted, emailed or overwritten by a file of the same name") and combining that with another comment from KB272414: MOD2000: How to Distribute a Replica Set for Indirect Synchronization which says... "Move the copy of the replica to the secondary computer. NOTE: It is important to move the replica rather than copy it to the secondary computer. A copy of the replica should not remain on the primary computer." However, in the Access 2000 Replication FAQ from Microsoft ("Frequently Asked Questions About Microsoft Access 2000 Replication" written by Michael Kaplan, Mary Chipman, Paul Litwin, Steve Thompson, and John Blaine) they do not say you have to move the copy of the replica. I think your comment refers to replicas once they are initialized, and I misread it. In the FAQ article they recommend using unbound forms to minimize replication data errors, since bound forms could hold a table open, blocking successful replication. Have you had any problems using bound forms, or are all your forms unbound? Cheers Nigel > Regarding my question "However, why do you say the copy on the > server must never be there?" and your response "Did I say that? I [quoted text clipped - 14 lines] > the copy of the replica. I think your comment refers to replicas > once they are initialized, and I misread it. OK, here's where the confusion is: There is a MOVE REPLICA command in Jet that moves the replica from one place to another and updates the replication tables to reflect that change of location for that particular replica. The most common place to see this command is in the menus of Replication Manager, but it's also available programmatically through the TSI Synchronizer and through JRO. Don't confuse the instruction to MOVE REPLICAS with a file system move -- it's not at all the same thing. If you MOVE a replica, it won't exist in its original location. Now, I don't understand why you'd ask the question, though. There's no reason to create extra replicas on the server at all. Just copy the main replica from the server to the destination locations, using the file system. Once those replicas are opened in place, they'll get assigned their new replica ID, but still retain all the information about the replica set that the replica they were copied from had in it. > In the FAQ article they recommend using unbound forms to minimize > replication data errors, since bound forms could hold a table > open, blocking successful replication. Have you had any problems > using bound forms, or are all your forms unbound? I don't use unbound forms very often. In replication, the only exception would be is that I edit memo fields in unbound textboxes, but I update them through a bound form recordsource. In general, I avoid situations where replication happens at a time when users are editing. However, if you're on a schedule, this can sometimes be impossible. If errors develop for this reason, they will go away as soon as you synch in a situation where the error condition is absent, so a scheduled synch overnight will take care of that. Going to all unbound forms is just ridiculous overkill, and is one of the many things in the replication FAQ that is unreliable advice, in my opinion. Going entirely unbound means you're losing out on the key strengths of Access -- it's throwing out the baby with the bathwater to avoid a problem that is only transient in the first place. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David Thanks for the information. It is true that I don't need to create a replica copy - I could just copy the main replica from the server to the destination locations. I just thought it was a bit easier to put the dos HUB copy in a folder called 'Deploy' and use that as the source for all remote HUBs. I copy from there and then open ReplMan at the remote site and initialize it. Cheers Nigel >Hi David > [quoted text clipped - 5 lines] >How do you schedule a synch with a replica which is not in a Synchronizers >list of managed replicas? Replication Manager shows a dotted line between the synchronizer and the unmanaged replica. IIRC, you just right-click on the line and choose "Schedule..." from the popup menu. >2 >A couple of weeks ago I wrote about scheduled synchs appearing in the [quoted text clipped - 19 lines] > >Nigel **********************jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security Thanks Jack - just the answer I needed. I suppose I should have guessed but, like so much with Access Replication, it is a brilliant and really useful technology which has a fairly poor GUI by Microsoft standards. In some ways the quirkiness of it reminds be of Lotus (uurgh) products. Cheers Nigel >>Hi David >> [quoted text clipped - 14 lines] >remove uppercase letters for true email >http://www.geocities.com/jacksonmacd/ for info on MS Access security > I suppose I should have guessed but, > like so much with Access Replication, it is a brilliant and really > useful technology which has a fairly poor GUI by Microsoft > standards. In some ways the quirkiness of it reminds be of Lotus > (uurgh) products. The ReplMan UI is one of the worst ever produced by MS. But it *is* discoverable. You can right click on things and get information about them. And I believe that if you read the ReplMan help file it would have told you how to set up a schedule. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.