Results 1 to 6 of 6
  1. #1
    Join Date
    Oct 2003
    Posts
    233

    Unanswered: Replicating a Desing master between 2 locations

    The db i am working on has a design master in CT and is replicated to a db in CT and another in LF

    Today the design changes in the CT design master would not sync to the CT DB. so in working on it, the whole thing is now screwy.


    I will create a new dm tomorrow in CT and then need to have that dm sync with the 2 locations. the location in another state is managed. the desing master and the db it replicates to in CT is not managed but has a line connecting it to the db so that i can right click and select sync now.

    i will have to start from scratch please HELP!!!!!!!!!!!!!!!!!!!!!!! if act one can give me step by step insturctions on how to do this, i will go to church agian!

    I attached a screen shot of what i have now and now need to add an unmanaged design master and create the scheduled syncronization line
    Attached Thumbnails Attached Thumbnails help.bmp  

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Please make screenshots JPGs ... please!!

    Sorry but I can't help here... I don't use replication at all :P
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    Oct 2003
    Posts
    311

    Not helpful at all

    Why bother replying?

  4. #4
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Dead right. My bad.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I've used replication - absolutely, absolutely hated it!! (I used the Star technology, then tried the Ring technology but I'm not sure which technology you're using.) As you've discovered, synching the changes can be problematic and really screw up your database (and I mean REALLY screw up your database). Especially if something hangs in the connection to the other nodes during updates of the changes. As I've noted below, I would always keep a non-replicated "master" mdb, make changes to that, and then do the replication wizard on it but read on.

    First and most important thing though, is to check your records and make sure you haven't ended up with orphaned records! (see below where you most likely have to re-synch changes and then check your master and eliminate orphans - then re-synch or re-replicate). Somewhere in that solution is doing the same thing for design changes (see links below). Having record identifiers like -2243343242332 really makes for problems and replication is NOTORIOUS for creating orphaned records (one of the main reasons I changed from using replication to letting my users connect to our network via Citrix and went that route (which Citrix was a fantastic benefit over replication - thank you Citrix!) No more synching of changes (which users that had slower modems absolutely loved as they didn't spend 20 minutes to 2 hours synchning design changes over their modems as well as synching record changes.) I also used SQL Server and unbound forms which made Citrix "FLY". Users connecting a half a state away and using slow modems could enter/search on recordsets in the millions which happened in less than a second.

    The ONLY reason replication was even considered in the first place was that some users had laptops and didn't always have an internet/network connection to get access to the records but they wanted to see and update the records in the mdb while at the airport/hotel (where you now have internet connection at almost all hotels.). That was the ONLY reason. Ultimately, this was unreliable anyway as data updates happened consistently with dozens of users constantly updating records so by the time the laptop user got to the airport, hundreds of data changes were already done. For the few users with laptops who wanted to take the data with them, a much better simple export/download of the data from when they did connect to the internet solution was done (i.e. the user downloaded the .txt data from an internet connection and I designed an mdb which simply imported that data quickly into their mdb and ran some update/append queries (making it non-updateable of course which they could live with.) There was one mdb for a laptop I did make it so they could update the data (which kept track of updates in separate tables and I then designed an export routine (.txt files) from that mdb for those records back to the server and then had a simple import routine to import the data into SQL Server (which essentially was just designing a few update/append queries to the server db's). This worked 1000 times better than the synchranization process. If you're users are always at static locations, you're really getting no benefit (and probably lots of headaches) using replication. If you're users are not at static locations, you heavily need to weigh how often data is being updated and again benefits of using replication versus keeping your sanity and maintaining it.

    I can't give you step by step instructions and would really need to see your setup but hopefully the Microsoft website links below will help you for replication problems as they have a procedure to fix replication synching/changes problems. I'm going from memory here (as it was over 10 years ago) but I believe it involved First making sure your replicated mdb's are synched and then re-creating the master and then re-replicating or re-synching. If I recall, it was a rather time-consuming "pain-in-the-butt" process (keep in mind that I had dozens and dozens of relational tables). I went to church almost every day and prayed for solutions but I ended up reading the help, re-reading the help, re-reading the help again, and trying this, then that, than this, than that again..etc...etc. until finally I had a good master which could be replicated on again. I recall learning to constantly make backups of a master that was not replicated (ie. before replication), made design changes to that, and then just re-did the replication wizard. This seemed to keep me from jumping off the cliff. Replication is NOT good to use on an mdb where you plan to make somewhat regular design changes (it's more of a use on a finished mdb product which rarely has ANY design changes - then you only have to deal with record synchranization problems.)

    Replication is even worse if you try to use unbound forms (which is sooo much easier if you were to use a Citrix type solution.) But Citrix is expensive if you are going to have many users (you have to pay a license per user connection.) If you have only 2 connection users, I'd HIGHLY recommend Citrix. Terminal Services was another option and less costly as it comes with Microsoft (Citrix also had a few printer driver issues as you had to install the printer driver the users had on the server.) Those issues were fixed though with later versions of Citrix. ASP pages for internet entry users was also a good solution (although I rarely used this method.) Again, Citrix was the best solution for all worlds.

    "Please" reconsider discontinuing using replication! I have yet to see an MSAccess replication process work without problems and I haven't seen any intention from Microsoft to continue supporting replication although they did make "some" improvements with it in later versions of MSAccess when I used it (I think Microsoft is phasing it out (or has - not sure as I've stayed far away from it since then) and the trend I've seen seems to be more of an MSAccess to SQL Server product type integration.) From your question though, it sounds like you only replicate to 2 other locations versus where I would replicate to dozens of other locations/nodes.

    You've probably already seen this but here is some info I found on MSDN and Microsoft's website regarding replication (with some very helpful tips) and fixing problems (again sorry this is the best I can do and I can't really help you much without seeing your actual setup. Even thinking about it though is giving me the shakes and starting to bring on a migraine):

    http://support.microsoft.com/kb/q207787/

    http://msdn.microsoft.com/archive/de...n_replicat.asp

    http://msdn2.microsoft.com/en-us/library/aa140024.aspx

    I hope that helps and that you'll sincerely reconsider a different method than continuing to use replication. That is absolutely the BEST advice I can give you. It was a bitch converting all the replication ID's to static ID's when I finally had enough problems for my hateful taste using replication - helpful tip - if you convert to a non-replication mdb, keep the large -234323433 non-static ID's in your new tables to use when populating records in the relational tables. I won't even get started on when I had to convert a very, very poor replication design to SQL server and to a non-replicated standard mdb (* shudder * shudder * shudder * here comes the shakes again - time to take my meds and a nap.)

    On the thousands of records and with all the consistently orphaned record problems I had (mostly due to users losing their connection while synchranizing), producing totals were almost always inaccurate. MSAccess Replication in my opinion is a failed and flawed product where it's essentially useless to try and keep referential integrity and was designed for the time when internet connections weren't plastered everywhere like they are today (I've heard they now have them at airports and even wireless on planes).

    Best of luck to you. Please let me know if the above links are of any help to you. Sorry about the lecture of all the cons but I had to tell you my experience with it. Others might be able to relate a better experience with it.
    Last edited by pkstormy; 03-14-08 at 14:37.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I had hoped to never see a record identifier like -234343453367 or 532432222212 in my life (then I went to a company which used Progress for it's databases) - go figure.

    Also note that I just updated the previous post (time 11:00 am).
    Last edited by pkstormy; 03-14-08 at 12:59.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •