 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / October 2006Indirect Sync A97 - Replication Manager
Is it true that Microsoft has now made the files necessary to implement indirect synchronization for A97 public? Does that mean it is no longer necessary to purchase a copy of a Developer's version to legally implement A97 indirect replication? I assume the combination of Microsoft's publicly available files and MichKa's TSI Synchronizer would be used to make indirect replication possible. Yes? No? Maybe? Other? TIA I Need Help > Is it true that Microsoft has now made the files necessary to > implement indirect synchronization for A97 public? Does that mean [quoted text clipped - 5 lines] > > Yes? No? Maybe? Other? MichKa, with MS's permission, was including the synchronizers in his A97 TSI Synchronizer download years ago. I've actually never implemented replication without ReplMan, so I can't say whether or not it works or not. I do know that someone posting here trying to do the same with Jet 4 (the files for that can be freely downloaded from MS) and was having problems on the workstations that didn't have ReplMan installed. I suspect that there are some registry keys that need to be written that don't get written without ReplMan unless you do it manually, but I don't know if that's also the case with Jet 3.5.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Is it true that Microsoft has now made the files necessary to > implement indirect synchronization for A97 public? Does that mean it [quoted text clipped - 4 lines] > > Yes? No? Maybe? Other? I've recently spent some time implementing indirect synchronization in a project I'm working on. I wanted to be able to configure my application to control synchronization programatically and to support both direct and indirect methods. I spent a lot of time experimenting with the TSI synchronizer and found that I could do just about everything I wanted to do by using it's properties and methods. However, I encountered some problems which I was not able to solve which forced me to use JRO and some querying of a system table to work around. I'll try to give you a quick overview of what I learned. There are people who have said that indirect synchronization can now be accomplished without installing Replication Manager but I have not been able to do that with Jet 4.0. The reason this is being said is that there is an update to replication manager which includes the jet synchronizer (mstran40.exe). It's true that if you download the service pack, jet40repl.exe, and install it, you will have a directory on your computer which will include the synchronizer. You can even start and stop it by double clicking on the file itself in windows explorer. You might be able to use the synchronizer with JRO at this point but you will not be able to control it using the TSI Synchronizer. I should explain that JRO has a method for initiating indirect syncrhonization which I do use but I never tried using it before I installed Replication Manager. That's why I said the JRO might work. However, before you can use the JRO method you need to set up a drop box on your computer. The easiest way I've found to do this is by using the TSI Synchronizer. I believe, however, that all that it does is to set a registry setting in the Transporter key under the jet 4.0 key. I have never tried to set this manually so I don't know if that is all that is needed or not. You would also need to make sure the synchronizer is running before you try to do indirect synchronization. The TSI object has a way of doing this, JRO does not. I tried installing the service pack alone without having Replicaton Manager installed and here's what happened: The TSI synchronizer object has a property called "running" which when set to true will start the jet synchronizer and when set to false will stop the jet synchronizer. The jet sychronizer must be running in order for an indirect sychronization to succeed whether you initiate the syncrhonization with the TSI Synchronizer, JRO or even Replication Manager. With only the service pack installed, when I try to execute the line of code "sync.running = True" I get an error stating that the synchronizer could not be found. As soon as I install Replication Manager I can run the same code with no error and the jet sychronizer starts and stops on command. I can't figure out what Replication Manager does to enable the TSI Synchronizer to be able to find the jet synchronizer. I tried adding a Replication Manager key to the registry manually and putting a SynchronizerPath key in it with a path to the jet synchronizer file but that didn't work. When I install Replication Manager it does exactly that and the TSI object begins to work. This tells me that something else is being done when Replication Manger is installed. I don't know if that something else is the installation of a file or the registration of a dll or a registry key or something else. All I know is that the TSI synchronizer can start and stop the jet synchronizer once Replication Manager is installed. Now for the next problem I encountered. After installing Replication Manager I could then synchronize indirectly by using the "synchindirect2" method of the TSI Synchronizer object. There are two methods available, one is "synchindirect" the other is "synchindirect2". The difference is explained in the help file. Basically I needed to use 2 because I wanted to be able to let the user know whether or not the synchronization succeeded and I also wanted to know when it was safe to stop the jet synchronizer from running. The synchindirect2 method returns an ExchangeID which can be used to get a HistoryItem object which has a status property which will let you know what the current status of the synchronization attempt is. I got everything to work flawlessly by using a timer event in the form I use to perform the synchronization. In the timer event I would check the HistoryItem.status every second until it returned either success, failure or cancel at which time I would report that to the user and stop the jet synchronizer from running by using the TSI Synchronizer object. I thought I was finished but then I decided that I would use the same form to enable the user to compact and repair the back end database as well as perform the synchroniztion. I discovered that when I attempted to compact the database after using the TSI Synchronizer object to do an indirect synchronization that I would get an error. For some reason, after the synchronization, an ldb file is left in the database directory which indicates that the database is opened by another user and this prevents me from being able to compact and repair the database. The only way I could get the ldb file to disappear was to close my front end application and then reopen it. My solution to this problem was to use JRO instead of TSI to initiate the indirect synchronization. I still use TSI to configure the settings I need such as the drop box folder and the databases which the synchronizer is managing and I still start and stop the jet synchronizer by setting the TSI running property. I only use JRO to do the actual synchronization. When I do this, the ldb file disappears as soon as the synchronizer is stopped. Don't ask me why, it just works. However, now that I'm using JRO in can't use TSI to get the ExhangeID so that I can track the status of the synchronization. Instead, I studied the MSysExchangeLog system table and found that I could query it and get the same information the the TSI HistoryItem gave me before. So now I query the MSysExchangeLog table of the database I'm synchronizing immediately after initiating the synchronization to get the ExchangeID and then I query it repeatedly in my timer event to check on the status until the status indicates that the synchronization is complete. This has been a long tedious process. It's not easy figuring this out because you have to have two separate computers set up and running just in order to test it. The most frustrating aspect is the almost complete lack of documentation on the subject. There's plenty of high level explanation about replicaton but very little documentation on the details behind the scenes. It's very disappointing to me that Microsoft hasn't done a better job than they have with the documentation of indirect replicaton and the jet synchronizer. I want to thank Michael Kaplan for making his TSI objects available. Without them I would never have figured out as much as I did. If Microsoft really wanted to make replicaton more available to Access developers they would have included all of the methods that the TSI objects contain in JRO. There's no reason why the couldn't have. They obviously don't want to make it easy for us. I can only assume they do this for financial gain. I guess they haven't gotten enough of our money yet. >> Is it true that Microsoft has now made the files necessary to >> implement indirect synchronization for A97 public? Does that [quoted text clipped - 8 lines] > I've recently spent some time implementing indirect > synchronization in a project I'm working on. . . . It's not clear to me that any of your travails are relevant to the question, as you were working with A2K and later, which offers JRO and has significant differences in replicaiton, and the questioner was asking about Jet 3.5 replication. MichKa bundled the synchronizer with the TSI Synchronizer back then, and I'd expect that it must have worked without ReplMan installed. Have you done as I suggested, and gone to MichKa's blog and contacted him to ask him about this issue? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > This has been a long tedious process. It's not easy figuring this > out because you have to have two separate computers set up and [quoted text clipped - 12 lines] > easy for us. I can only assume they do this for financial gain. I > guess they haven't gotten enough of our money yet. They do it because they don't want people to use Jet -- they want them to buy SQL Server licenses. And Jet replication in Access is basically dead in terms of future development. Access 12 will support all legacy Jet functionality, but will not add new functionality. And the new method for sharing data with Access will require a Sharepoint server. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >> Is it true that Microsoft has now made the files necessary to >> implement indirect synchronization for A97 public? Does that mean it [quoted text clipped - 99 lines] > >This has been a long tedious process. Your description is much appreciated. Thanks you. I'm sure it will be useful to me as I try to do the same with A97. Has anybody had any luck with A97 using TSI Synchronizer but no Replication Manager? Mr. Fenton says that he "thinks" it is doable, but does not offer specific experience because, I think, he has been successful with other methods. Thank you. I Need Help > I'm sure it will > be useful to me as I try to do the same with A97. I don't think it will be much use at all, because replication was altered in extremely significant ways from Jet 3.5 to Jet 4. JRO did not even exist for Jet 3.5, so there was *no* alternative to the TSI Synchronizer for programmatic control of replication (that's precisely why MichKa took the time to create it). > Has anybody had any luck with A97 using TSI Synchronizer but no > Replication Manager? Mr. Fenton says that he "thinks" it is > doable, but does not offer specific experience because, I think, > he has been successful with other methods. I've only used it with ReplMan installed, so I don't know if it works without the problems Tom encountered with Jet 4. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ In my searching for answers to many questions I recall reading instructions for how to enable indirect synchronization in Access 97 using TSI without installing Replication Manager. I believe that the synch35 download from TSI includes all of the files you need. If you do some searching online, I'm sure you'll find some answers. If I get a chance, I'll look for some of the links I found and post them for you. As far as using the TSI synchronizer after it's installed, there shouldn't be any difference between 3.5 and 4.0 so I might be able to help you with those questions. I'm a little short of time this weekend or I'd find more information for you. Good Luck! > >> Is it true that Microsoft has now made the files necessary to > >> implement indirect synchronization for A97 public? Does that mean it [quoted text clipped - 111 lines] > > I Need Help >In my searching for answers to many questions I recall reading instructions >for how to enable indirect synchronization in Access 97 using TSI without >installing Replication Manager. I would be very happy to see it. > I believe that the synch35 download from TSI >includes all of the files you need. I have that already so I have the files, if correct. > If you do some searching online, I'm >sure you'll find some answers. I did that and didn't find. :-((( > If I get a chance, I'll look for some of the >links I found and post them for you. That would be very kind. >As far as using the TSI synchronizer after it's installed, there shouldn't >be any difference between 3.5 and 4.0 so I might be able to help you with >those questions. I have difference computers and can run any type of tests. Just a little to get started is all I think I need. I'm willing to do many legs work. > I'm a little short of time this weekend or I'd find more >information for you. You are very kind. I will wait. I Need Help What I was thinking of is actually the information in the help file which is included with the TSI Synchronizer download. There is information about what files you need to install if you don't want to use Replication Manager and where to put them. You can find that information by looking under "Indirect Synchronization" in the index of the help file. From that topic there is a link for "redistribution" which lists the files you need to distirbute with you application. There are instructions for creating a registry key as well which is the same as the registry key that Replication Manager creates when it's installed. Have you read the help file yet? >What I was thinking of is actually the information in the help file which is >included with the TSI Synchronizer download. There is information about what [quoted text clipped - 7 lines] > >Have you read the help file yet? Yes. Many times. I am admittting that I must be missing something because things don't work. Let's start with the basics. Download TSISynch35 from www.trigeminal.com. Unzip into separate folder. Copy all files (I know don't need all, but what the heck) to: C:\Program Files\Common Files\Microsoft Shared\Replication Manager 3.5 Create registry key as per help file: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Replication Manager Create string value of: SynchronizerPath Populate string value with where TSI Synch files put (same as above): C:\Program Files\Common Files\Microsoft Shared\Replication Manager 3.5 Create new mdb file. Set reference to TSI Synchronizer 3.52 (make sure it shows up and the box is checked). Reference set by browsing to: C:\Program Files\Common Files\Microsoft Shared\Replication Manager 3.5\synch35.dll Create test form with single command button that has the following as the click event code: Dim sync As Synchronizer Set sync = New Synchronizer Debug.Print sync.Version When I click on the command button the second line pops an error: 429: ActiveX component can't create object. I know it must be something simple. Can you spot additional step I need? Thanks I Need Help >>What I was thinking of is actually the information in the help file which is >>included with the TSI Synchronizer download. There is information about what [quoted text clipped - 49 lines] >I know it must be something simple. Can you spot additional step I >need? OK, left out step of: regsvr32 synch35.dll After that, second line no longer errors and debug window shows 3.52.5024. I'll post later with next question. Thanks I Need Help It probably doesn't matter, but the only files that you need to put in the Replication Manager directory are the jet synchronizers mstranXX.exe and mstraiXX.exe. You only need the mstran file for indirect synchronization, the mstrai file is for internet synchronization. I put the TSI synchronizer file ,synch40.dll (in my case), in my application directory. I remember reading a thread somewhere in which Michael Kaplan stated that he prefers not to put it in the system directory. He doesn't say that it won't work but he thinks it's better not to. You can get it to work without registering it but registering it does make it a little easier to set the reference. The real test is whether or not the TSI Synchronizer object is able to control the Jet Synchronizer. You can test this by doing the following: Dim sync As Synchronizer Set sync = New Synchronizer sync.running = True 'You should see the jet synchronizer pop up on the windows task bar after this line of code. MsgBox "Delay to check if synchronizer is running" sync.running = False 'The jet synchronizer button on the task bar should disappear. set sync = nothing Make sure that the jet synchronizer is not running before you execute this code. If it is already running you will get an error. If not, the synchronizer should start running, the message box should pop up and then the synchronizer should stop running after you click "ok" on the message box. I was never able to get this to work without having Replication Manager installed first but I only tried it with 4.0. When I would set sync.running to True, I would get an error stating that the synchronizer could not be found. I'll be very curious to hear if you are able to do this without first installing Replication Manager. Your original question is one that I've researched at length and have never seen a definitive answer to. I find it odd that it's so difficult to get a yes or no question answered on this topic. Hopefully your experience will help to answer this question for both of us. Good Luck! >>>What I was thinking of is actually the information in the help file which >>>is [quoted text clipped - 70 lines] > > I Need Help >It probably doesn't matter, but the only files that you need to put in the >Replication Manager directory are the jet synchronizers mstranXX.exe and [quoted text clipped - 32 lines] >yes or no question answered on this topic. Hopefully your experience will >help to answer this question for both of us. If by original question, you mean: "Is it true that Microsoft has now made the files necessary to implement indirect synchronization for A97 public?" I think the answer is clearly yes, because I was able to run your test and the MSTRAN35.EXE process began and ended as per your comments. I am close to running a real test, but I have one other question at the moment: When should the Jet Synchronizer be running? Does it need to be running 100% of the time that any replica that is managed is potentially being edited? [I wouldn't think so.] Does it need to be invoked immediately before a programmatic indirect synchronization is executed? [I think so.] Does it need to remain running until the aforementioned programmatic indirect synchronization completes? [I think so.] I presume that to shut down the Jet Synchronizer would preclude any further progress on an indirect synch. That is, even if the remote dropbox becomes available, nothing will happen. Basically, I'm confused about the order of things when you have a laptop which will be potentially on the move during the day and then plugged back in to the remote network at night. Thanks I Need Help (although less than before) > I am close to running a real test, but I have one other question > at the moment: When should the Jet Synchronizer be running? Does > it need to be running 100% of the time that any replica that is > managed is potentially being edited? [I wouldn't think so.] . . . Why? Only if you have scheduled synchs, which can only happen when the synchronizer is running. I believe that missed synchs occur the next time the synchronizer is started, but I could be misremembering that. Obviously, if you have a replica farm with scheduled synchs, the synchronizer needs to be running all the time *somewhere*. > . . . Does it need to be > invoked immediately before a programmatic indirect synchronization > is executed? [I think so.] . . . It has to be running first for the synch to take place, yes. > . . . Does it need to remain running until the > aforementioned programmatic indirect synchronization completes? [I > think so.] Yes, of course. The synchronizer is the process that does all the actual work of indirect synchronization, copying files to the remote synchronizer's dropbox and processing the files in the local dropbox. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ "> >> . . . Does it need to remain running until the >> aforementioned programmatic indirect synchronization completes? [I [quoted text clipped - 4 lines] > synchronizer's dropbox and processing the files in the local > dropbox. David is absolutely correct, the synchronizer needs to keep running until the synchronization process is complete. The trick is determining when it's safe to shut it down. That's the reason for the synchindirect2 method. When a synchronization starts, a record is written to the MSysExchangeLog table and a unique id is assigned to that record in the ExchangeID field. Then as the synchronizer does its job it ocassionally updates the Status field in that table with an integer indicating the current status of the exchange. The synchindirect2 method returns the exchangeID when it is executed so that you can periodically check the status of the synchronization. When the status indicates complete, failed, or cancelled it's safe to shut down the synchronizer. The TSI library includes constants to represent those values so you don't need to use the integers in your code. To check an exchange status with the TSI synchronizer, you need to use the HistoryItem object. It's documented in the help file. You'll need to use the HistoryItemOfExchangeID method to return a historyitem. Then you can check the status property of the historyitem object. You need to destroy the historyitem object after each use and create a new one in order to get the current status. There are no events that can be used with indirect synchronization as there are with direct synchronizations. It is also possible to check the MSysExchangeLog directly in order to see the current status. It's probably easier and more efficient to use the TSI objects. I did it the hard way because of the difficulties I described back in my original post. Since you're running Access97 you probably have no reason not to use the TSI objects. I like to understand what's going on under the hood so I'm glad I took the time to figure this out. Like I've said before, not much of this is documented so I'm sharing my experience with this group in order to add to the available documentation that can be found on the web. I don't consider myself an expert programmer and I know that I'm far from perfect so please forgive any errors or incorrect terminology in my explanations. Thanks for letting me know how you made out. I'm glad to hear that you can perform indirect synchronizations without installing replication manager. It gives me incentive to keep trying to make it work with 4.0. >"> >>> . . . Does it need to remain running until the [quoted text clipped - 41 lines] >perform indirect synchronizations without installing replication manager. It >gives me incentive to keep trying to make it work with 4.0. I think I spoke too soon. :(( I have everything "working", but nothing works. I could go on at length about how I think everything is working, but I will try to be brief (and probably fail). 2 computers. On LAN. Direct syncs work fine (both using Access GUI or using my front-end over TSISynch object). TSISynch docs say that it will do indirect if told to do indirect, even if shares are visible, so being on Lan shouldn't be a problem, right? Tried IndirectSynch and IndirectSynch2. Neither does anything different. Tried from each end. Same result each time. Exchange log shows each attempted sync with the dreaded "No suitable synchronizer found." message. Per trigeminal, a direct sync should get everything back working again. Nope. I can direct sync either direction (using Access GUI or using my front-end over TSIsynch object) and it will show up on the Exchange logs as a direct sync with no errors. But executing an indirect sync through TSIObject falls over. Strange stuff, of course. Let's see. One way (from B => A) wingman.sgn gets created (with computer name - that is, about 8 byts of information) and that's it, in the correct (local) dropbox. But no other files are generated and the Exchange Log has the error message regarding no suitable synchronizer. MSTran34 running on both computers. TSISynch-object based front end, run on each computer, shows that the dropbox is set properly on each and that, well, everything else is, too. My front end has a combo box for selection of a local replica and, once selected, it displays all of the members of the replica set associated with that replica, along with all of the managed local replicas (well, the one managed local replica, anyway), the dropbox name, the synchronizer name, the retention period, whether it is a design master.... basically most of the TSI-Synch properties. The display of the replica set members is in a list box with ReplicaName, Description, MachineName, ReplicaID, UNCName and Synchronizer ID. Everything looks ok to me (but that isn't saying much). I guess it is the Empty Full Replica solution next (on the weekend), but I'm not holding out much hope for that considering trigeminal says a direct synch should fix the problem, too, and it doesn't. Any other ideas? I Need Help (more today than yesterday...going the wrong direction! ;-)) > Any other ideas? Permissions on the two machines? That is, what user is logged on on the two machines? Do they have the same rights on the dropboxes? If you don't have a domain controller, you have to set up the user on both boxes with the same username. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >> Any other ideas? > > Permissions on the two machines? That is, what user is logged on on > the two machines? Do they have the same rights on the dropboxes? If > you don't have a domain controller, you have to set up the user on > both boxes with the same username. I've been testing my application on a very insecure peer-to-peer network where most people log onto their machines as administrator. I log onto my machine with a different user name and I'm able to perform indirect synchronizations with replicas on other people's machines. The shares are set up to allow any user to have access. Your point is a good one, though. Make sure that the users on both machines have permission to access the drop box folders on both machines. I've read several posts where you express the opion that most of the problems people experience with indirect synchronization are due to network configuration issues not jet or access. You are correct; getting the replicas located and configured correctly is extremely important. Please forgive me for paraphrasing your statements, David. If I'm mistaken please correct me. I've read so much about this over the last month that I sometimes mix things up. > I think I spoke too soon. :(( > [quoted text clipped - 42 lines] > I Need Help (more today than yesterday...going the wrong direction! > ;-)) I know your frustration. I think that the problems you are having have nothing to do with the TSI Synchronizer. First of all, I don't believe that an indirect synchronization will occur unless the mdb files are located in non shared directories. It seems like it should but I've read many times that it won't. I tried similar experiments and ended up creating a whole new replica set before I finally got everything to work. The empty replica solution is probably the correct way to fix your problems if you are working with production data and don't have the luxury of starting over. I believe what is happening is that when replicas perform direct synchronizations the synchronizerID that is created in the system tables refers to a virtual synchronizer, not the indirect synchronizer (mstranXX.exe). As a result, because you performed direct synchronizations between these replicas already, the replica which you are trying to sync with indirectly has a synchronizer ID which does not correctly identify the jet "indirect" synchronizer. This is speculation on my part since I've not seen any documentation to confirm this. I experimented with several different ways of retrieving the correct synchronizer ID and got the best results by specifying the machine name. I still ran into some trouble with that until I finally got my replica set configured correctly. The synchindirect methods of the TSI Synchronizer object accept several different values for their arguments; the one I settled on was the machine name. I don't know how TSI uses that argument to initiate the indirect synchronization but I would guess that it looks up a synchronizerID in the system tables to get it. When I use JRO to perform indirect synchronizations I use the machine name as well. What I've realized is that you shouldn't be concerned with which specific replica you are synching with but rather the synchronizer you want to work with. The synchronizer name is usually the same as the machine name. You need to make sure that both replicas are in unshared folders and that they are both managed by their perspective jet synchronizers and that both synchronizers have drop boxes set up. I do believe that I was able to perform direct syncs and then unshare the folders and perform indirect syncs with the same replicas. But that was not until after I had indirect synchronizations working correctly. My experience was that most of the problems I had were related to the way I had my replica set configured not the code I was using. >> I think I spoke too soon. :(( Well, consistent with David's assertions as reported by you I delved into the system's permissions. While A=>B had unfettered access, B=>A had a real problem. That has been cleared up. Things are wide open now in both directions. And a bit of progress on the indirect sync's. Now, an indirect sync from B=>A, run from B while the synchronizer is running, shows up in the Exchange Log with a status code of 0, rather than 3. I call that progress, I think. What needs to be done to actually make the synchronizer start? I'm a bit concerned that since I rebuilt the replica set completely, that the synchronizer on B, which was set to manage "DB1.MDB" in a particular folder is looking for the OLD file, rather than the new one, although the name of the file is the same and I deleted the original while the synchronizer wasn't running and I started up the synchronizer after I had already replaced DB1, so I would think it should find it, if it ever goes looking for it. I guess I'm asking whether it is mandatory to put an entry into the schedule of the synchronizer through TSISynch's SetFullSchedule or SetSimpleSchedule in order for it to attempt to initiate the sync. Something tells me the answer is yes (how else does it know to kick things off?). Am I close? Thanks I (obviously still) Need Help > What needs to be done to actually make the synchronizer start? > I'm a bit concerned that since I rebuilt the replica set [quoted text clipped - 5 lines] > DB1, so I would think it should find it, if it ever goes looking > for it. Remember that the data regarding which replicas are managed is kept in the replication tables. If you don't unmanage a replica explicitly, that entry will remain in the system tables. However, keep in mind that your replacement replica may have the same name/path, but it can't possibly have the same ReplicaID. I would say that the replacement managed replica is a major problem -- I'd unmanage, synch direct, then manage again. This should clear any references to the old managed replica and communicate that information to the other replica. > I guess I'm asking whether it is mandatory to put an entry into > the schedule of the synchronizer through TSISynch's > SetFullSchedule or SetSimpleSchedule in order for it to attempt to > initiate the sync. Something tells me the answer is yes (how else > does it know to kick things off?). I don't recall that you needed to shedule anything to have it work. But I've always worked with the TSI Synchronizer in scenarios in which there *was* a scheduled synch, just not between the replicas that I was synching indirectly. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > And a bit of progress on the indirect sync's. Now, an indirect sync > from B=>A, run from B while the synchronizer is running, shows up in > the Exchange Log with a status code of 0, rather than 3. I call that > progress, I think. A status code of 0 means that a synchronization has been requested. It will remain 0 until it the synchronizer on the other machine responds. At least that is what I think happens. All I can say for certain is that if the synchronizer on the other machine isn't running, the status will never change from 0 to 1. It's also possible that the other synchronizer is running and the status is still 0. In that case there is some bad information in the replicas tables. This goes back to having the replica set configured correctly. I've discovered that the replica set can be very fragile. You have to be very careful about making changes once you have replicas set up and managed. From your description, I'd say that the replica on B is being managed by it's local synchronizer since you did get an entry in the Exchange log. What I would suggest is that you make a new replica from that replica and put it on machine A. To be safe, try putting it in a new location then start managing it with the synchronizer on that machine then try to initiate a synchronization from A=>B. I assume that you know that you shouldn't open the new replica until after you have it where you want it unless you use the TSI Synchronizer to move it. This is critical. > What needs to be done to actually make the synchronizer start? You can start the synchronizer by setting the TSI Sychronizer running property to true. You can also start it by finding it in Windows Explorer and double clicking on it. It doesn't matter which method you use but you will get an error if you try to start it with the TSI object if it is already running. There's no way to start the synchronizer on the other machine from a remote machine. You have to start it manually before you try to synch with it. Normally you will be synching with replicas on a server which leaves the synchronizer running all of the time. When you install Replication Manager on a machine it puts a short cut to the synchronizer in the start up folder so that the synchronizer starts up whenever the machine is booted. You should probably do the same. It is possible to create a schedule for synchronizations using TSI but initiating a sychronization won't start the synchronizer automatically. Normally, scheduled synchronizations involve direct syncs with replicas on the LAN. Indirect syncs are done primarily because one of the machines does not have a direct connection to the LAN. The remote machine would normally be the one that initiates the indirect sync. > I'm a > bit concerned that since I rebuilt the replica set completely, that [quoted text clipped - 4 lines] > synchronizer after I had already replaced DB1, so I would think it > should find it, if it ever goes looking for it. I don't think it will look for it by name. I think it identifies replica by their replicaID. I thing that the replicaID of the new replica will be different than the old one even if they have the same name and are in the same location. I want to emphasis how fragile the configuration of the replica set can be. I have a desktop machine at home that I use to test my work on. It has Replication Manager installed and I use replication manager to manage that replica. I have a laptop with another replica on it. On the laptop I manage synchronizations with the TSI synchronizer. I use code in my front end which uses TSI to tell the sychronizer to manage that replica. Earlier today I was modifying some code in my front end while working on the desktop PC. Without thinking about it, I initiated an indirect synchronization from the desktop machine using code. The code in my front end uses the TSI synchronizer to start the jet synchronizer before initiating the indirect synchronization. Usually I would use Replication Manager to do it from this machine. It resulted in an error which said that the same replica cannot be managed by more than one synchronizer. After that, I couldn't get an indirect sychronization to work again even by initiating it from the laptop or from Replication Manager on the desktop. I probably could have solved it with an empty replica but I took the easy way out and just created a new replica for my laptop. It's not good practice to continue creating new replicas everytime there's a problem with the replica set, however. What I'm finding is that the best route is to set everything up correctly once and then don't mess with it. >> And a bit of progress on the indirect sync's. Now, an indirect sync >> from B=>A, run from B while the synchronizer is running, shows up in [quoted text clipped - 56 lines] >different than the old one even if they have the same name and are in the >same location. Does TSISynch expose the replicaID of the managed replicas? The help file appears to say that the replica set associated with managed replicas only exposes the managed replica's name. >I want to emphasis how fragile the configuration of the replica set can be. >I have a desktop machine at home that I use to test my work on. It has [quoted text clipped - 17 lines] >What I'm finding is that the best route is to set everything up correctly >once and then don't mess with it. If I ever get there, I will certainly take THAT advice. At this point, I want to thank both you and David for helping me. Even though I'm not there, yet, I have the feeling I'm getting closer and that wouldn't be possible without the help I'm getting here. Some of what I'm doing now is being a bit stubborn with my currently failing because I would rather see if I can figure out how to hurdle these little problems now rather than later. While it might be easy for me to obliterate my test replica set and start over now I don't want to be in this position with a real replica set and not have already "been there, fixed that". At least that is where I'm coming from at the moment. With that said, I opened up a share between A and the directory with the replica on B and did a direct sync. Then I closed the share. Now, when I do an indirect sync from B=>A, the files are created on A in the appropriate dropbox and B's Exchange Log registers a new row with a status code of 1. This is definite progress!!! From A=>B however, I get the same result: wingman.sgn appears briefly in the folder with the replica set and then disappears. A's Exchange Log soon thereafter shows a new row with a failed indirect sync. Well, I noticed I had two copies of msrpfs35.dll on A (one in windows\system, the other in the c:\program files\common files\microsoft shared\replication manager 3.5 folder so I deleted it from the c:\windows\system32 folder. But that didn't help matters. Maybe it will after I reboot. At this point I have one question: Now that the files created by B are sitting in A's dropbox, what do I need to do in order to have the synchronizer on A take those files and process them, which will undoubtedly insert the new records in A's mdb file that were created in B's mdb file before the indirect sync was initiated. Yes, the synchronizer is running on A (it has to be or else the files created by B when the indirect synchronization was initiated wouldn't have found there way to the dropbox on A, right?). Thanks Still, obviously, I Need Help > Does TSISynch expose the replicaID of the managed replicas? The help > file appears to say that the replica set associated with managed > replicas only exposes the managed replica's name. You are correct about the replica items in the managedreplicas collection but you can get the replicaID from a replica object which is a member or the replicaset collection. For example: dim mySync as Synchronizer dim rep as replica 'Tip: if you have JRO referenced in your application make sure to use an explicit reference for this variable. JRO has a replica object as well. I user "dim rep as synch40.replica" in my code. You would probably use "dim rep as synch35.replica". dim reps as replicaset set mySync = new synchronizer mySync.DatabaseName = "C:\MyData.mdb" set reps = mySync.replicaset for each rep in reps debug.print rep.replicaID next This code will give you replica id's for all replicas in the replica set of MyData.mdb. You can compare the replica name property of each replica to that of the replicas in the managed replica collection to see if the specific replica you are examining is managed. > At this point I have one question: Now that the files created by B are > sitting in A's dropbox, what do I need to do in order to have the [quoted text clipped - 4 lines] > by B when the indirect synchronization was initiated wouldn't have > found there way to the dropbox on A, right?). That's not right. The files in A's dropbox were probably put there by the synchronizer on machine B. Thats why the dropboxes need to be shared. I just ran a quick test with my set up. I initiated an indirect sync from my A to B while the sychronizer on B was not running and 2 msg files were created in B's dropbox folder. The status of the exchange is 1 (in progress) and will remain as 1 until I start the synchronizer on B. The sychronizer on A has to keep running until this process is complete, however, or the sync will never get completed. Remember, both synchronizer have to be running simultaneously for an indirect synchronization to take place. This is one of the tricky parts of trying to determine when it's safe to stop the synchronizer from running. If the synchronizer on the target machine is not running, then the synchronization status on the initiating machine will hang at 1 indefinately. You will need to have some code to let the process time out and stop the attempted synchronization if you intend to stop and start the synchronizer. For now, you should probably try starting both synchronizers manually and just let them continue running. Once you've successfully synchronized then you can worry about starting and stopping the synchronizer. Like I said before, usually the synchronizer on the target machine is set up to run all the time. > Thanks > > Still, obviously, > > I Need Help >> At this point I have one question: Now that the files created by B are >> sitting in A's dropbox, what do I need to do in order to have the [quoted text clipped - 14 lines] >get completed. Remember, both synchronizer have to be running simultaneously >for an indirect synchronization to take place. PMFJI - I find this thread very interesting and informative. I have always *assumed* that the two synchronizers worked, well, asynchronously during the indirect sync communications session. In other words, I thought that A created its message files in B's dropbox, and then temporarily dropped out of the equation. It is irrelevant whether or not B's synchronizer is running. A's synchronizer could be stopped after it creates the message files in B's dropbox. When B's synchronizer is launched, it sees the message file in its dropbox, and proceeds to process it. At the end of its processing, B creates a message file in A's dropbox. Whether or not A is running is irrelevent to the success of creating the message file. When A's synchronizer is launched again, it sees the message file in its dropbox. In this case, it happens to be the message required to finish the two-way sync that A happened to commence, but it could just as easily be a message file from any other synchronizer. It could even be a message file about a sync that was *initiated* from B. If both synchronizers are running when all this takes place, then the elapsed time is minimized. However, either synchronizer can be off-line when the other synchronizer is creating the message file, and the indirect synch will still proceed as far as it can go. When the target synchronizer comes back online, then it proceeds with processing all message files in its dropbox. Each synchronizer has a agent that periodically polls its own dropbox to see if there are any incoming message files. At least that's my picture of how it works. Correct me if I am wrong. >This is one of the tricky parts of trying to determine when it's safe to >stop the synchronizer from running. If the synchronizer on the target >machine is not running, then the synchronization status on the initiating >machine will hang at 1 indefinately. You will need to have some code to let >the process time out and stop the attempted synchronization if you intend to >stop and start the synchronizer. I don't think that's correct, but I may be wrong. My experience is only with Jet 35 and Replication Manager. Other environments may be different. ********************** jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security >>> At this point I have one question: Now that the files created by B are >>> sitting in A's dropbox, what do I need to do in order to have the [quoted text clipped - 51 lines] > > At least that's my picture of how it works. Correct me if I am wrong. You are correct! I just tested it and it does work the way you explained. My test, however, was done without making any changes to records in either replica so it was the simplest scenario possible and it took an additional exchange to complete. I initiated the sync from A which put one file in B's dropbox. I then stopped A's synchronizer and started B's sychronizer. The msg file in B's dropbox disappeared and a new msg file appeared in A's dropbox. Then I stopped B's sychronizer and started A's again. The message in A's dropbox disappeared and another msg file was created in B's dropbox. I stopped A's synchronizer and started B's and this time the msg file disappeared from B's dropbox and no new files appeared in A's drop box. If this was an active replica set and many users were making changes and synchronizing I imagine that there would be a need for several messages to be passed back and forth between synchronizers. That means that a sychronization could take a very long time to complete if both synchronizers were never running at the same time. In a scenario where a remote user only connects to the network and synchronizes ocassionally, this could cause replicas to be out of sync much of the time. Thanks for correcting my explaination. This thread is helping me learn a lot more than I knew before. >>This is one of the tricky parts of trying to determine when it's safe to >>stop the synchronizer from running. If the synchronizer on the target [quoted text clipped - 8 lines] > only with Jet 35 and Replication Manager. Other environments may be > different. I'm not sure what you mean. If you initiate an indirect sync in 3.5 and the other synchronizer is not running, what will happen? Won't the status recorded in MSysExchangeLog stay as "1"? From what I've seen, this is the only way to track the status of an indirect sync. The TSI object uses the historyitem and its status property seems to coincide with the status field of the MSysExchangeLog table. While it's true that you can let the synchronization happen asynchronously, that isn't acceptable in the application I'm working on. In my case, remote users are sales people in the field who connect through VPN's infrequently. I want them to wait for the synchronization to complete before they shut down there connection. The only way to do this is to track the status of the exchange. Right now, I allow 10 minutes for the synchronization to complete before I let the attempt time out and shut down the synchronizer. Hopefully, this will never happen. Does this make sense? > ********************** > jackmacMACdonald@telusTELUS.net > remove uppercase letters for true email > http://www.geocities.com/jacksonmacd/ for info on MS Access security >>>This is one of the tricky parts of trying to determine when it's safe to >>>stop the synchronizer from running. If the synchronizer on the target [quoted text clipped - 22 lines] >minutes for the synchronization to complete before I let the attempt time >out and shut down the synchronizer. Hopefully, this will never happen. If you initiate the sync and the other synchronizer is not running, then it will create the message file as I explained. I was alluding to the fact that the thread has been about TSI Synchronizer and Jet 4.0. I dunno whether there are subtle differences compared to RM and Jet 4.0. I doubt that the behaviour is changed, but I don't know for certain. I haven't looked into the status of the current sync's like you have done, so I can't offer any first-person experience about checking for whether the current sync is completed. My *guess* is that the status will stay as 1 until such time as the other synchronizer comes online and completes the second half of the sync. That can be any time in the future -- it's not required (from a technical sense) that the whole process be completed at one time. Your application may have different requirements. >Does this make sense? >> >> ********************** >> jackmacMACdonald@telusTELUS.net >> remove uppercase letters for true email >> http://www.geocities.com/jacksonmacd/ for info on MS Access security ********************** jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security >>> At this point I have one question: Now that the files created by >>> B are sitting in A's dropbox, what do I need to do in order to [quoted text clipped - 23 lines] > asynchronously during the indirect sync communications session. . > . I think this is a common misconception based on a lack of considering the architecture of an indirect synch. Synchronizer A drops msg files in Synchronizer B's dropbox. Synchronizer B puts files in Synchronizer A's dropbox. Consider: Assuming that synchronizer B is the remote synchronizer, in the case of a 2-way synch, how does it know to start putting the files in Synchronizer A's dropbox? Obviously, there has to be communication between the two synchronizers. Furthermore, for a one-way synch, say A->B, Synchronizer B has to know to look in the dropbox. Perhaps whenever it's running it polls the dropbox. I don't know, but I strongly doubt that it does, because otherwise orphaned msg files would eventually get used, and they quite clearly do not (lmsg files left over from a filed synch are never processed). Given that it's pretty obvious Synchronizer B doesn't poll its local dropbox looking for msg files to process, it must of necessity be the case that there is communication between the synchronizers. Consider also: have you ever noticed how there are groups of msg files and MDB files, and then those disappear and then more appear? This is because for referential integrity reasons, all changes cannot be sent in a single synch (in the simplest case, you can't delete a record, for instance, until it has been added first). Thus, even for a one-way synch, the remote synchronizer has to be told by the local "Hey! I'm finished now -- you can pick up those files and process them. When you're done, let me know, 'cause I've got more to send to you!" So, I would say that your assumption is simply wrong. I've never assumed any such thing myself, because my experience tells me that msg files left by an incomplete synch never get used at all. And I know for a fact that they can be deleted without any impact on future synchronizations. > . . . In > other words, I thought that A created its message files in B's [quoted text clipped - 7 lines] > B creates a message file in A's dropbox. Whether or not A is > running is irrelevent to the success of creating the message file. This is simply wrong, so far as I can tell. > When A's synchronizer is launched again, it sees the message file > in its dropbox. In this case, it happens to be the message [quoted text clipped - 14 lines] > At least that's my picture of how it works. Correct me if I am > wrong. All my experience with indirect replication tells me that you are wrong. >>This is one of the tricky parts of trying to determine when it's >>safe to stop the synchronizer from running. If the synchronizer on [quoted text clipped - 7 lines] > only with Jet 35 and Replication Manager. Other environments may > be different. I've been following your many posts in the forum lately, and you've provided a lot of very good information, but all of the above is completely at variance with my own replication experiences. And almost all of my replication work, and *all* of the indirect replication, has been with Jet 3.5. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ . >> I have always *assumed* that the two synchronizers worked, well, >> asynchronously during the indirect sync communications session. . [quoted text clipped - 13 lines] > Synchronizer A's dropbox? Obviously, there has to be communication > between the two synchronizers. > Furthermore, for a one-way synch, say A->B, Synchronizer B has to > know to look in the dropbox. Perhaps whenever it's running it polls [quoted text clipped - 5 lines] > must of necessity be the case that there is communication between > the synchronizers. David, that didn't prove to be the case in my tests. I believe that the synchronizers do poll the dropbox locations. I remember reading an old post from Michka where he stated that the synchronizer polls much too frequently than he would prefer. I assume he meant that it polls for messages left by other synchronizers. > Consider also: have you ever noticed how there are groups of msg > files and MDB files, and then those disappear and then more appear? [quoted text clipped - 5 lines] > process them. When you're done, let me know, 'cause I've got more to > send to you!" Actually, it appeared in my tests that the communication between synchronizers all took place through the messages left in the dropboxes. In your scenario above, the synchronizer doesn't need to yell "Hey!", it just sends the messages when it's ready and waits for the other synchronizer to find them. I imagine that the synchronizer can tell the other synchronizer it's finished by including that information in one of the message files. The problem I have with using asynchronous sessions is that it would definately take too long to complete a synchronization because, in most cases, there needs to be several communications sent back and forth in order to complete the sync. This seems like a recipe for conflicts and out of sync replicas. > So, I would say that your assumption is simply wrong. > [quoted text clipped - 59 lines] > And almost all of my replication work, and *all* of the indirect > replication, has been with Jet 3.5. >>>> At this point I have one question: Now that the files created by >>>> B are sitting in A's dropbox, what do I need to do in order to [quoted text clipped - 30 lines] > >Synchronizer B puts files in Synchronizer A's dropbox. Yes, I understand that. >Consider: > >Assuming that synchronizer B is the remote synchronizer, in the case >of a 2-way synch, how does it know to start putting the files in >Synchronizer A's dropbox? Obviously, there has to be communication >between the two synchronizers. I am not sure it is "obvious". What it *seems* to me is that Sync B finds a message file in its dropbox via polling, and processes the file. Contained in the message file is information that it originated from Sync A. Sync B *knows* that it did not initiate the session (one of the attributes exposed by the RM history is "initiated here"). Therefore, Sync B knows that it must communicate with Sync A to complete the session. That behaviour can be explained easily without requiring communication between the two synchronizers. >Furthermore, for a one-way synch, say A->B, Synchronizer B has to >know to look in the dropbox. Perhaps whenever it's running it polls >the dropbox. I don't know, but I strongly doubt that it does, I don't know for certain either, however, I think polling is a simpler explanation than synchronizer-to-synchronizer communication. Also, *how* would such communication take place -- via what IP Port? AFAIK, all that is required for successful indirect sync is clear access to the other guy's dropbox. Should be fairly easy to test by attempting a synchronization from A to B when B is not running. Then shut down A, start up B, and see what it does. Then shutdown B, startup A, and observe. Of course, clear access to the dropboxes must be maintained at all times. I would test it now, but my home network doesn't have RM installed. Another possible test: sync from A to B while B is offline. Preserve the message files elsewhere. Shutdown A and start B. Restore the message files into the dropbox. If they are processed, then polling is "certainly" (???) involved. I've always assumed that polling was part of the robustness of indirect sync, and I think it's one of the reasons that the recommended location for the dropbox is *on* the synchronizer computer, but I stand to be corrected. Consider: if an initiating synchronizer is successful in creating a message file in another synchronizer's dropbox, then it has fulfilled all the "hazardous" portions of the synchronization. "All" that remains to fulfill the current part of the synchronzation is for the receiving synchronizer to open the message file on its local hard drive -- no WAN, LAN, or other flakey communication is required. A single-computer solution (ie, polling) is much more robust than a solution that requires computer-to-computer communication. To me, it just stands to reason that once the message file is created, you don't want any more cross-WAN communication. >because otherwise orphaned msg files would eventually get used, and >they quite clearly do not (lmsg files left over from a filed synch Yes, I have seen that behaviour, although I cannot explain why they don't get processed. >are never processed). Given that it's pretty obvious Synchronizer B >doesn't poll its local dropbox looking for msg files to process, it >must of necessity be the case that there is communication between >the synchronizers. I don't think that is necessarily correct -- I don't accept that it's "given" or "obvious" that polling doesn't occur. Absence of evidence is not evidence of absence. >Consider also: have you ever noticed how there are groups of msg >files and MDB files, and then those disappear and then more appear? [quoted text clipped - 5 lines] >process them. When you're done, let me know, 'cause I've got more to >send to you!" Polling can explain that behaviour. >So, I would say that your assumption is simply wrong. Could be... but then again, I don't think that your explanation is bullet-proof. >I've never assumed any such thing myself, because my experience >tells me that msg files left by an incomplete synch never get used >at all. > >And I know for a fact that they can be deleted without any impact on >future synchronizations. As I stated in another message, I did not know that and I defer to your experience. >> . . . In >> other words, I thought that A created its message files in B's [quoted text clipped - 9 lines] > >This is simply wrong, so far as I can tell. Should be fairly easy to test. You contend that both synchronizers must be running simultaneously in order for an indirect sync to occur. I contend that the sync can proceed, albeit more slowly, if either synchronizer is running, and that the sync will be completed successfully after both synchronizers have had their "kick at the can". Consider this observed behaviour: Sync B is offline for whatever reason. Sync A initiates a session, placing message files in Sync B's dropbox. When Sync B comes online, it processes all the messages successfully. How does that jibe with your contention that both synchronizers must be running in order to complete the synchronization? However, it's probably a moot point from an operational perspective. I think we would both agree that the best situation would be to have an always-running hub synchronizer with which the remotes would synchronize. Here's a situation that I don't know how it would react: remote Sync A initiates a session with Sync B that happens to be off-line, but its dropbox is visible. It creates the message files in Dropbox B. Failing to hear back from B, Sync A goes offline (eg, remote user disconnects from VPN). Sometime later, Sync B goes online, sees the message file and processes it. It tries to communicate with Sync A, but the dropbox is not visible. Clearly that would result in a failed communication -- but what would Sync B do in the future? Would it continue to try to communicate with A, or would it give up? I don't know, but the answer is important to the OP's situation. >> When A's synchronizer is launched again, it sees the message file >> in its dropbox. In this case, it happens to be the message [quoted text clipped - 33 lines] >provided a lot of very good information, but all of the above is >completely at variance with my own replication experiences. Is it at variance, or is it just a different interpretation of the same behaviour? I think the only place we disagree is whether synchronizer-to-synchronizer communication is required. And as I stated clearly, I stand to be corrected. I read a very good book recently (title something like "design of everyday objects") that talked about the various mental pictures that people build for objects (eg, software). The mental picture held by the designer, programmer, and user may not always be the same. Neither of us had any input to the design of the replication, and we both have built a mental picture of how it works, based on our observations. Who's to say whether either mental picture is correct? >And almost all of my replication work, and *all* of the indirect >replication, has been with Jet 3.5. Likewise. And I think that your experience is *way* more extensive than mine, but that doesn't necessarily mean that your mental picture is correct and that mine is incorrect. You haven't provided any compelling evidence that makes me change my mind. ********************** jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security > However, it's probably a moot point from an operational perspective. I > think we would both agree that the best situation would be to have an [quoted text clipped - 11 lines] > communicate with A, or would it give up? I don't know, but the answer > is important to the OP's situation. I think this is the critical issue in this conversation. The test I did worked because both machines remained online while I started and stopped the synchronizers. The simplest possible synchronization scenario took three steps. A sent messages to B, B sent a message back to A, and then A sent a message back to B again. I believe that in any one of those exchanges, if the machine attempting to send the message had not found the dropbox on the other machine, the exchange would have failed. I'll have to test this to know for sure and I'm not able to do that right now. If my guess is correct, then I need to amend my original assertion that it's important for both synchronizers to be running simultaniously to; a connection between the two machines must exist whenever either of the synchronizers are running and a synchronization attempt is in progress. This has been a very interesting and informative discussion but I'm not sure if it has addressed the problem that "I need help" was having. "I need help" had been successful in getting one synchronizer to send a message to the other's dropbox but then nothing happened from there. Either the connection wasn't maintained, one of the synchronizers wasn't running, one of the replicas involved in the synchronization is not being managed by the correct synchronizer, or there is some sort of corruption in one or both of the replicas. By corruption, I mean that there is some information in a system table which is incorrect. It could have something to do with the way in which the replica set was created. We need to hear back from "I need help". >>> When A's synchronizer is launched again, it sees the message file >>> in its dropbox. In this case, it happens to be the message [quoted text clipped - 59 lines] > remove uppercase letters for true email > http://www.geocities.com/jacksonmacd/ for info on MS Access security >>>>> At this point I have one question: Now that the files created >>>>> by B are sitting in A's dropbox, what do I need to do in order [quoted text clipped - 50 lines] > That behaviour can be explained easily without requiring > communication between the two synchronizers. Yes. I rethought this whole thing overnight and realized I was being to categorical, and that message files and polling would be sufficient as a communications channel. >>Furthermore, for a one-way synch, say A->B, Synchronizer B has to >>know to look in the dropbox. Perhaps whenever it's running it [quoted text clipped - 13 lines] > times. I would test it now, but my home network doesn't have RM > installed. Well, my experience with indirect replication always involved having both synchronizers running, and that was fragile enough. Introducing this concept of asynchronous replication seems to me to be asking for even more problems in what is already a very fragile operation. > Another possible test: sync from A to B while B is offline. > Preserve the message files elsewhere. Shutdown A and start B. > Restore the message files into the dropbox. If they are processed, > then polling is "certainly" (???) involved. But that can't possibly work. If Synchronizer B is offline, Synchronizer B's dropbox won't be available, unless you're using the non-recommended architecture with all your dropboxes on a central server. Given that Synchronizer A writes message files to Synchronizer B's dropbox, if Synchronizer B is offline, Synchronizer A has no access to drobox B, so it couldn't possibly work. Thus, asynchronous syncs can only work when both sides of the synch are online, though, presumably, it doesn't require both synchrnoizers to be running. > I've always assumed that polling was part of the robustness of > indirect sync, . . . "Robustness" is not a word that comes to my mind in connection with indirect synchronization! > . . . and I think it's one of the reasons that the > recommended location for the dropbox is *on* the synchronizer [quoted text clipped - 9 lines] > it just stands to reason that once the message file is created, > you don't want any more cross-WAN communication. It also doesn't require any machine-to-machine protocol, such as RPC or the like, so I think you're right and I was completely wrong. >>because otherwise orphaned msg files would eventually get used, >>and they quite clearly do not (lmsg files left over from a filed >>synch > > Yes, I have seen that behaviour, although I cannot explain why > they don't get processed. To me, that's evidence that indirect replication is already fragile enough that I"m not about to try to introduce more latency in the process by trying it when only one synchronizer is running. [] > Consider this observed behaviour: Sync B is offline for whatever > reason. Sync A initiates a session, placing message files in Sync > B's dropbox. When Sync B comes online, it processes all the > messages successfully. How does that jibe with your contention > that both synchronizers must be running in order to complete the > synchronization? This is the scenario you outlined above, and it seems to me it is fatally flawed, in that if Sync B is offline, its dropbox will be inaccessible, unless you've set up Sync B with a remote dropbox, which is not a recommended configuration. > However, it's probably a moot point from an operational > perspective. I think we would both agree that the best situation > would be to have an always-running hub synchronizer with which the > remotes would synchronize. I can't see any advantage to doing it any other way. > Here's a situation that I don't know how it would react: remote > Sync A initiates a session with Sync B that happens to be > off-line, but its dropbox is visible. . . . That is impossible, unless you're using the remote dropbox architecture, which has always been a non-recommended setup. > . . . It creates the message files in Dropbox B. Failing > to hear back from B, Sync A goes offline (eg, remote user [quoted text clipped - 5 lines] > it give up? I don't know, but the answer is important to the OP's > situation. I don't know. I'd never consider setting things up in a manner that would make it possible for such a scenario to occur. [] >>I've been following your many posts in the forum lately, and >>you've provided a lot of very good information, but all of the [quoted text clipped - 5 lines] > synchronizer-to-synchronizer communication is required. And as I > stated clearly, I stand to be corrected. I suspect you are right that the communication is through message files in the dropboxes, which are polled. > I read a very good book recently (title something like "design of > everyday objects") that talked about the various mental pictures [quoted text clipped - 4 lines] > works, based on our observations. Who's to say whether either > mental picture is correct? In this case, it's quite obvious that the people writing the documentation for replication have completely failed in their task. This kind of thing should have been explained in the basic replication documents. It's clearly not, since I've read all of them many times, and I know I wouldn't have missed an explanation of how replication works. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ [ big snip] >In this case, it's quite obvious that the people writing the >documentation for replication have completely failed in their task. >This kind of thing should have been explained in the basic >replication documents. It's clearly not, since I've read all of them >many times, and I know I wouldn't have missed an explanation of how >replication works. Sounds like we are basically in agreement. One clarification about what is meant by offline: I was taking the stricter interpretation in that the dropbox was visible and accessible, but the synchronizer was not running. It sounds like you were interpretting it to mean that the dropbox did not exist either. In the latter sense, then I would agree that both synchronizers must be running for a successful sync. In the former case, either synchronizer can be stopped. How could that happen besides by implementing the non-recommended method of locating the dropbox off-computer? Hung computer or failure to start the synchronizer after a reboot are two situations that come to mind. ********************** jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security > [ big snip] > [quoted text clipped - 14 lines] > synchronizers must be running for a successful sync. In the former > case, either synchronizer can be stopped. I was reading "offline" as "not connected to the network," which seems to me to be the generally accepted definition of the term. > How could that happen besides by implementing the non-recommended > method of locating the dropbox off-computer? Hung computer or > failure to start the synchronizer after a reboot are two > situations that come to mind. Eh? Just not connected to whatever network is the transport for the communication would put it offline. Since my assumption is a hub/spoke architecture, with the spokes initiating the synch, this should never be an issue (on the hub, the synchronizer would always be running). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > From A=>B however, I get the same result: wingman.sgn appears > briefly in the folder with the replica set and then disappears. > A's Exchange Log soon thereafter shows a new row with a failed > indirect sync. This doesn't sound right. The dropbox on the local machine should have wingman.sgn as soon as that machine's synchronizer is started up. Both dropboxes should have wingman.sgn created before you attempt to initiate a synch, since that's an indication that the synchronizer that manages those dropboxes is running. If it's not there on both of them, then that means your dropboxes are not properly configured. [] > At this point I have one question: Now that the files created by B > are sitting in A's dropbox, what do I need to do in order to have [quoted text clipped - 4 lines] > files created by B when the indirect synchronization was initiated > wouldn't have found there way to the dropbox on A, right?). Remember the way it works: Synchronizer A puts files in Synchronizer B's dropbox. If Synchronizer B is failing to complete the synch, then the files in its dropbox have not been processed, and can simply be deleted. Any new synchronization will check the generations in the actual files you're synching, rather than worrying about what's happened with the msg files in the dropboxes. So, you can safely delete the files in any dropbox that result from a failed synch. Any information in them will be sent again in the next synch. That much I know for certain to be true, since I've done it a gazillion times. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >Remember the way it works: Synchronizer A puts files in Synchronizer >B's dropbox. If Synchronizer B is failing to complete the synch, [quoted text clipped - 7 lines] >next synch. That much I know for certain to be true, since I've done >it a gazillion times. Aha! There's been occasions on my system when something went awry, and one of the dropboxes accumulated tons of message files. I was never certain whether they could be deleted safely, and if subsequent sync's would repeat the information. Thanks for that confirmation. ********************** jackmacMACdonald@telusTELUS.net remove uppercase letters for true email http://www.geocities.com/jacksonmacd/ for info on MS Access security > I know your frustration. I think that the problems you are having > have nothing to do with the TSI Synchronizer. First of all, I > don't believe that an indirect synchronization will occur unless > the mdb files are located in non shared directories. It seems like > it should but I've read many times that it won't. My understanding is that only JRO allows you to control that. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > You need to make sure that both replicas are in unshared folders > and that they are both managed by their perspective jet [quoted text clipped - 3 lines] > replicas. But that was not until after I had indirect > synchronizations working correctly. One little hint for this: Remember that every hard drive on NT-based versions of Windows has a hidden administrative share. Your C: drive has C$, your D: drive, D$, etc. So, assuming you have administrative permissions, you could always use the administrative share for any direct synch, without needing to set one up. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > I tried installing the service pack alone without having > Replicaton Manager installed and here's what happened: The TSI [quoted text clipped - 14 lines] > synchronizer file but that didn't work. When I install Replication > Manager it does exactly that and the TSI object begins to work. For what it's worth, I have gotten it working to do an indirect synch using only the TSI Synchronizer and no Jet 4 ReplMan installed on either end. The key for getting the .Running property to work was in having the SynchronizerPath registry key. The harder problem was getting the fact that the replicas were managed into the system tables of the replicas. I still haven't quite figured out how I made that happen yet, but I did. So, I'm offering experience contrary to yours -- I've been able to get indirect replication working with only the TSI Synchronizer and no ReplMan at all (and no JRO). 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.