Replies

Wendell
Does LogMeIn allow a person sitting at the “controlled” computer to also control the computer, or is it locked? In other words, is LogMeIn an option for me allowing someone to see what is happening on my computer, with me having control of the mouse and keyboard?

Try:

http://www.pacificdb.com.au/MVP/Code/UnReplicate.htm%5B/url%5D

Sorry, but I have never used the TSI unreplicator.

Did you do all the synchronizations from the Design Master? When you created the 2 new replicas from the Design Master, had you deleted all its dead replicas?

One reliability issue with dead replicas is if you start doing massive deletions and such, those changes will be carried inside the replica set “forever”, waiting for an opportunity to inform the dead replicas about the changes. Of course, that opportunity will never arise, thus your replicas will carry excess baggage forever.

Thanks, Hans.
None of the settings in the Compatibility tab of the program’s shortcut made any (improved) difference in the program’s running. Setting it to 256 colours was a definite step backwards!

I am not familiar with the Compatibility Wizard. Can you point me in the right direction?

If I understand correctly, you have deleted all the replicas whose names and/or folder names are bogus, and you are still left with 30 entries of “valid” UNC names for the 3 valid replicas. You want to delete “dead’ replicas that are seemingly OK. Is that correct?

I am going out on a limb here because I have not done this process. No guarantees!

I would move each of the new replicas to a safe location, leaving its home folder empty. Then I would try to synchronize with it, and since it is now missing, it will be deleted from the replica set. Repeat until they are all gone. Then move the preserved replica back to its correct location, and open it with Access. It should be recognized as a new replica, and properly added to the replica set. Of course, it **may** carry with it all the names of the 30 dead replicas, in which case your hard work was for nought.

Hope this helps, but as I said, there are NO guarantees!!!

Perhaps you have a computer kicking around that you can rename with the name of your old server. Share a folder and give it a share name to match the old share name. Create the appropriate folder structure and attempt to sync with the dead replica in that folder.

Or…. as you said, just live with it.

I noticed you are running an older version of PD6. My copy is 6.0.3.4 which is (AFAIK) the latest version. Downloadable from the website accessible via the Help menu.

Anybody else running PD6 under Vista? I am really disappointed with its performance. It often “goes away” and becomes unresponsive for 20-30 seconds, especially when it is first opened or when moving to a new folder. Also, the small icons in the left column of the Details view are invisible after moving to a new folder. Only by pressing F5 to refresh the display are they visible. Anybody else see the same behaviour? It’s *almost* enough to make me ditch PD6 after many years and revert to the inferior Windows Explorer.

It is expected that you cannot delete items manually from the system tables. Only the database engine itself can do that. Attempting to sync with a non-existant replica in an existing folder is the only way to delete the dead replicas.

As for your inability to view the system tables in your Design Master — I can’t explain that. Did you enable the viewing of both System and Hidden objects in the Tools > Options > View menu?

BTW – before I learned about dead replicas, I created a replica set with dozens of dead ones. Never did delete them all; I eventually unreplicated the database and created the replica set again from scratch. Big job…

I doubt that the write-protected will influence whether or not the deletion works properly. Yes, it should be corrected, but it probably won’t influence the results.

One of the hidden system tables created when you replicate a database is called something like “MSysReplicas”. It lists all the replicas in the set. I would bet that it shows *many* copies of your dead replica, especially if you have been using bad habits… My understanding (and I stand to be corrected) is that each time you do a sync with a non-existent replica, it will delete one record from the MSysReplicas. My advice would be to keep deleting those phantom dead replicas until they all disappear from MSysReplicas.

Other than that… I hope someone else can kick in. There is an active Usenet newsgroup about replication. You can access it via Google Groups; look for microsoft.public.access.replication.

Glad to help!
You said that you moved the replica to another folder. I hope that you NEVER use that replica again — especially if you sync it with another member of the replica set. Moving a replica will cause Jet to issue it with a new (internal) ReplicaID. For all intents and purposes, it is a NEW replica and its previous location becomes a dead (unreachable!) replica.

See http://www.dfenton.com/DFA/Replication/ind…d_replica.3F.22%5B/url%5D

Hans is correct (as usual!). The *folder* for the replica must exist, but the *file* must be non-existent before Access will remove the dead replica. In your case, you must attempt to synchronize with PETESLAPTOPAccessInsurancMainData.mdb, which means that you must have a computer named PETESLAPTOP with a Share named Access, containing a folder named Insuranc. There should *not* be a file within that folder when you attempt to synchronize with it.

You may have been confused by the difference between UNC file names and Drive: filenames.

HTH

Interesting stuff. That link lead me to http://bertk.mvps.org/html/missingrpv.html%5B/url%5D , which hints that Vista can delete the Restore Points if it is not certain of their history. While it doesn’t answer my question in so many words, it does make me suspect that Vista deleted them without notification.

I have increased the size of the shadow area from about 4.5 GB to 6 GB. The used and allocated space was about 1.4 GB.

Thanks for the help.