Results 1 to 11 of 11
  1. #1
    Star Lounger
    Join Date
    Mar 2002
    Location
    Edinburgh, Scotland
    Posts
    80
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Synchronisation (2000)

    HELP!! Have a database at work set up by someone else with a design master and 3 replicas. My Access knowledge is that of "baby designer" in that I can design applications, but am still getting to grips with programming. 3 Outworkers synchronise from p.c.s at home to 3 replicas on zip drives which are then uploaded and synchronised via an integral zip drive onto main p.c. on site. They have had problems since database designed 2 years ago, but now problems getting really bad. Both design master and replicas full of outdated information and database size is large. I have little experience of synchronised databases, but my feeling is that this method of synchronisation is inherantly insecure, and that, if we have to continue to run it, new replicas might be required. Can anyone give me some pointers urgently on what I should know before I start?? Where do I start??

  2. #2
    Gold Lounger
    Join Date
    Feb 2001
    Location
    Sint Niklaas, Belgium
    Posts
    2,778
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Synchronisation (2000)

    Francois

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Synchronisation (2000)

    We'd be glad to help, but what problem do you want help with? What do you mean by outdated information? Certainly, any data that was previously entered is still going to be there unless you have a utility to archive it.

    Creating new replicas won't change the data in the database. Please explain exactly what problem you're encountering and what you want to do about it.
    Charlotte

  4. #4
    Star Lounger
    Join Date
    Mar 2002
    Location
    Edinburgh, Scotland
    Posts
    80
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Synchronisation (2000)

    Thanks for replies. One of the problems is there is no archive utility built into this database and it is now huge. Replicas won't synchronise properly due to "unknown error" -1603, or simply drops information. Does this sound familiar to anyone?

  5. #5
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,624
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Synchronisation (2000)

    The care and feeding of replicated databases is pretty much like any other database, at least in theory. In practice, they do tend to be more problematic than unreplicated ones. I've not seen the 1603 error, or ever seen info dropped, but it's certainly possible. Does someone routinely do a conflict resolution between all copies of the replicated database? I suspect that may be where some of the problems lie, and it is a major pain to deal with, but very necessary. The situation that causes this kind of this is that two (or more) users change the same record in their replicas, and then when you try to synchronize you get error messages. In other cases, someone may change a record, and someone else delete it, causing the same problem.

    As to getting huge, how large is huge. I presume they are still fitting on ZIP drives, so they must be under 200MB. I have seen Access 2K databases grow to 500MB and still work fine, so being big isn't necessarily a cause for concern. The traditional way of solving that problem is to either delete or archive records (to another database) at the design master and then do a compact and repair. Another strategy to consider in order to reduce some of the problems with a growing list of conflicts is to regularly delete and recreate new replicas. It also sounds like you might want to do the same with the design master. It's a fairly ugly process to remove replication and then recreate it, but it should solve the flaky issues you are having. I assume your database is split into a front-end and a back-end. If not you should do that, which will require recreating the replica anyhow.

    The bottom line is that replication does work fairly well - we have clients who have been using it successfully for several years - but it can be a pain to maintain! Let us know how you fare in resolving the problems.
    Wendell

  6. #6
    Lyn Mac
    Guest

    Re: Synchronisation (2000)

    Still on sync and replication (Access2k):

    At the office we a have a split DB. The b-e is replicated (1 DM, 2 replicas installed in 2 other PCs) while the f-e is not. The b-e is about 6MB, while the f-e is about 12MB. Since we are not yet on a network and we don't have zip drives, we use the floppy disk of 1.44MB to distribute the DB with the use of WinZip 8.0. During sync the b-e is zipped, brought to the PC with the DM, unzipped to a temp folder, opened and sync with the DM, the zipped again, transferred to another PC, and unzipped again for use of other users.

    Now the questions are the following:

    1. Is this process of sync using WinZip healthy or proper?

    I have had experiences that Access reports a successful sync but found out that some records are missing.

    2. Does it matter that sync is being done from the replica or the DM? That is, open the replica and start sync with the DM as opposed to the DM being opened and start sync with the replica. Our method now is the first option.

    TIA

    Lyn

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Synchronisation (2000)

    I don't recommend syncing replicas directly to a design master. If you build your replicas from an intermediate replica, you will have a fallback position when (not if, but when) your design master blows up on you. Alternatively, you have the design master to create a new secondary replica if that one explodes.

    What you're doing with WinZip is just a step away from what Briefcase Replication does for you, and if you don't have a network, you have no choice but sneaker net for syncing the files. You would still be advised to create an intermediate replica though just as insurance.
    Charlotte

  8. #8
    5 Star Lounger
    Join Date
    Jan 2001
    Location
    Vancouver, Br. Columbia, Canada
    Posts
    632
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Synchronisation (2000)

    Whenever you move a replica from one computer to another, the jet replication system realizes that it's been moved and adds a new replicaID into its internal list of replicas. So, by moving your replicas via Zip disks, you have inadvertently created a whole bunch of bogus replicas. Furthermore, Jet keeps track of items for it to delete from every replica (so-called tombstones), and it will keep them in the database for the retention period (default is 1000 days). That's the source of your database growth.

    You are experiencing the unfortunate fruit of using replication inappropriately. Once a replica is used on a computer, it must never be used on another computer.

    See www.trigeminal.com for a lot of valuable information. Bottom line -- there is no safe way to use replication via zip disks -- it is designed to be used over a network connection (e.g. dialup connection).

    Your recourse now is to copy the structure into a new database and convert it to a design master. Make a replica from that. Import the data into the replica. Create additional replicas. There is a utility on www.trigeminal.com that will allow you to safely move the replicas onto your remote computer (TSISynch).

    Hope this helps.
    --------------------------------------------------
    Jack MacDonald
    Vancouver, Canada

  9. #9
    Star Lounger
    Join Date
    Mar 2002
    Location
    Edinburgh, Scotland
    Posts
    80
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Synchronisation (2000)

    Thanks for this. Company have now taken advice and are wishing to move to a terminal server, where outworkers connect to a database with a modem and work in real time. Many thanks for the responses to my query.

  10. #10
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,624
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Synchronisation (2000)

    Before you make that leap there are a few things to consider. First, using a terminal server will mean that your users have slower response times - it is the best of the WAN solutions, but there's nothing faster than having a database on your local hard drive, even if it is a replica. And if you are planning to use a modem, unless you have ISDN (at 144kb), your users will probably be unhappy. ISDN, DSL or Cable Modems (or T1) most people can live with.

    Second, if you are very careful, and always copy the files to and from the same location, then you don't run into the tombstone problem previously noted, as the replica is always opened and modified by the same user on the same computer. Charlotte's advice is also excellent. It is always best to create an intermediate replica, and syncronize everyone, including the design master, from it.

    Third, your databases are not that large relatively speaking. And it is quite possible to shrink the data side of things by archiving records out to another database, and then deleting them. You will of course need to compact and repair to see the size shrink.

    Finally, if you do decide to unreplicate, it's a tedious task described in a KB article. You will want to read it carefully before you start, and then you might want to use a tool available from www.Trigerminal.com that automates much of the tedious stuff. In the database world things are seldom simple.
    Wendell

  11. #11
    Star Lounger
    Join Date
    Mar 2002
    Location
    Edinburgh, Scotland
    Posts
    80
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Synchronisation (2000)

    Dear WendellB et al , many thanks for this, I will pass your comments on to those who buy! As I am only at the beginning stage of using VBA, and am used to small, local networks, I am assuming that programming for a terminal server is something I should not attempt and am sloping my shoulders and attempting to leave the country before someone thinks its a good idea I should try!

Posting Permissions

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