Question Steps to recover replication after DM and replicas expires

[Theknees]

A few weeks ago a database that we replicate stop replicating because the replicas in the set did not synchronize within the retension period.

There were only two replicas in the set and the Design Master was also out of date.

I rebuilt the database from scracth and re created the DM and created a new set of replicas.

When I redistributed the replicas and tried to synchronize, I received the following error at both locations:

'The two replicas you are attempting to synchronize are from different replica sets.'

I understand what the message means but if I replaced the entire set how can synchronize be seeing a replica from the previous set.

Here is what was done:

Created the database.
Merged data from the expired replicas into the new database ( Use How to Make a Replicated Database a Regular Database’ )
Created the Design Master from new database.
Created two replicas from design master.
Distributed the new replicas to two servers and ftp server.

Our synchronization is done through code in a small VB6 application and is set up as follows:

Two Replicas each reside on different Windows Server.
When synchronize occurs, a copy of the replica is downloaded to a client machine from the windows server
A copy of the other replica is downloaded from the FTP server to the client machine
Once both replicas are on the client machine synchronization occurs.
The copy from the client machine replaces the replica on the Window Server.


Any help is appreciated.

 

[dfenton]

The steps you describe sound right. Given the error you received, I was going to suggest that you created a replica from each of the unreplicated databases, but you said you merged the data all into one MDB and then re-replicated. That sounds correct.

Perhaps you have some old replicas sitting around somewhere and a synch with one of those was attempted?

 

[Theknees]

Thanks, you are correct the client machines both had previous copies which I had to replca as well.

 

[dfenton]

Thanks, you are correct the client machines both had previous copies which I had to replca as well.

Well, now it sounds like you *did* do it wrong.

The steps you should have taken were:

1. unreplicate a replica (the Jet Replication Wiki FAQ, http://dfenton.com/DFA/Replication/, has a list of tools to make that as easy as possible).

2. import all its data into a new, blank MDB.

3. take the first of the other replicas and merge its data into this new MDB.

4. repeat until the data from all replicas is merged. This may involve doing them all at once, since records might have been updated simultaneously in more than one replica.

5. after all the data is merged into the new unreplicated MDB, create a replica from it.

6. distribute new replicas from this single replica set to your users.

I'm not certain what you did now, but it sounds like you unreplicated each replica, then re-replicate each unreplicated file and then expect them to be able to synch. Once the data is unreplicated, there's no going back using replication.

Sorry if I'm misunderstood, though.

 

[Theknees]

I may not have been as clear as I should have been as well.

I followed the steps that you've described exactly.

When I posted this problem there was one thing that I should have done that I missed.

The client PCs where the synchronization occurs still g=had versions of the old replicas. I replaced those with the new replicas and everything worked.

Thanks again for your quick reply.

 

[dfenton]

I'm glad you clarified that -- that will make it more helpful for others who might read this discussion.

 

[Theknees]

FYI

The document that describes how to create a regular database from a replica is missing an important step http://support.microsoft.com/kb/290052 .

A copy of the steps are below.

1. Create a new database.
2. Import all the objects, except for the tables, from the replicated database into the newly created database.
3. Close the new database, and then open the replicated database.
4. In the Database window, click Queries under Objects, and then click New.
5. In the New Query dialog box, click Design View, and then click OK.
6. Select the first table in the Show Table dialog box. Drag all the fields to the Field row, except for the fields that were generated for replication (Gen_OLE Fieldnames, s_ColLineage, s_Generation, s_Guid, s_Lineage). If your application requires one of these fields that was created by replication, go ahead and add it to the query.
7. On the Query menu, click Make Table. In the Table Name box, select the current table name. Click Another Database, and add the name of the database that you created in step 1. Run the query.
8. Repeat steps 4 through 7 for each table in the replicated database.
9. Close the replicated database, and then open the new database. Re-create all indexes and relationships that existed in the replicated database.
10. After you've completed steps 1 through 9, compact and then repair the new database. The new database should be approximately the same size as before replication and will not contain any replication properties.

Step # 2 states that you should import all objects except the tables. If you import the objects under the query group, then these objects may refer to tables that do not exist yet. During the import MS Access will try to correct these so that they work without the tables. You must correct all of the queries.

 

[dfenton]

The document that describes how to create a regular database from a replica is missing an important step (http://support.microsoft.com/kb/290052).

First off, why do it manually? Michael Kaplan's add-in takes care of all this for you:

http://www.trigeminal.com/lang/1033/utility.asp?ItemID=7#7

A copy of the steps are below.

1. Create a new database.
2. Import all the objects, except for the tables, from the replicated database into the newly created database.
3. Close the new database, and then open the replicated database.
4. In the Database window, click Queries under Objects, and then click New.
5. In the New Query dialog box, click Design View, and then click OK.
6. Select the first table in the Show Table dialog box. Drag all the fields to the Field row, except for the fields that were generated for replication (Gen_OLE Fieldnames, s_ColLineage, s_Generation, s_Guid, s_Lineage). If your application requires one of these fields that was created by replication, go ahead and add it to the query.
7. On the Query menu, click Make Table. In the Table Name box, select the current table name. Click Another Database, and add the name of the database that you created in step 1. Run the query.
8. Repeat steps 4 through 7 for each table in the replicated database.
9. Close the replicated database, and then open the new database. Re-create all indexes and relationships that existed in the replicated database.
10. After you've completed steps 1 through 9, compact and then repair the new database. The new database should be approximately the same size as before replication and will not contain any replication properties.

Step # 2 states that you should import all objects except the tables.

Step 2 assumes you are doing things COMPLETELY WRONG, i.e., replicating front-end objects. Only data tables should ever be replicated, so if you're doing things right, it's irrelevant whether or not you have Name Autocorrect on or off.

If you import the objects under the query group, then these objects may refer to tables that do not exist yet. During the import MS Access will try to correct these so that they work without the tables. You must correct all of the queries.

Well, if in STEP 1 (creating the new database) you turn OFF Name Autocorrect, it won't be an issue. Nobody with any sense at all leaves Name Autocorrect turned on as it's one of the most common sources of corruption out there. Also, it propagates its changes without confirmation so it often makes mistakes. It's a "feature" that never should have been added in the form in which Microsoft implemented it.

 

[Theknees]

Well, if in STEP 1 (creating the new database) you turn OFF Name Autocorrect, it won't be an issue. Nobody with any sense at all leaves Name Autocorrect turned on as it's one of the most common sources of corruption out there. Also, it propagates its changes without confirmation so it often makes mistakes. It's a "feature" that never should have been added in the form in which Microsoft implemented it.[/quote]

Mr. Fenton,

You should not assume that everyone who posts in this forum as the necessary experience to know that 'Name Autocorrect' should be turned OFF.

Posting this kind of comment to anyone is insulting and unnecessary.

 

[dfenton]

Posting this kind of comment to anyone is insulting and unnecessary.

No, it's not. It's a statement of fact from the standpoint of anyone who gives careful thought to the "feature" and has any experience with it at all will know that it's a bad idea to leave it turned on.

Certainly the replication document is very flawed, and mostly constitutes documents that were created before Jet 4, and didn't always get edited to account for new "features" in Access/Jet 4.

Indeed, I would guess this is an Access feature and not a Jet "feature," and thus something of an "orphan" in regard to whether or not it should be mentioned in the documentation of a Jet feature. Of course, given that the article talks about forms/reports/etc., it's clearly an Access article, and should advise that Name Autocorrect should be turned off if you're making the mistake of replicating anything other than tables.

But from where I sit, the huge error is in writing the article to account for replicated front-end objects, instead of saying you shouldn't do that. If they recommended that users replicate only tables, then there'd be no need to worry about the side issue of Name Autocorrect.

And, oh, BTW, usually, people say THANK YOU when they've been offered good advice, even if it may have been delivered in a somewhat bracing manner. Getting pissy about the tone is likely to mean that serious developers will not answer your questions in the future.

 

[Theknees]

No, it's not. It's a statement of fact from the standpoint of anyone who gives careful thought to the "feature" and has any experience with it at all will know that it's a bad idea to leave it turned on.

Certainly the replication document is very flawed, and mostly constitutes documents that were created before Jet 4, and didn't always get edited to account for new "features" in Access/Jet 4.

Indeed, I would guess this is an Access feature and not a Jet "feature," and thus something of an "orphan" in regard to whether or not it should be mentioned in the documentation of a Jet feature. Of course, given that the article talks about forms/reports/etc., it's clearly an Access article, and should advise that Name Autocorrect should be turned off if you're making the mistake of replicating anything other than tables.

But from where I sit, the huge error is in writing the article to account for replicated front-end objects, instead of saying you shouldn't do that. If they recommended that users replicate only tables, then there'd be no need to worry about the side issue of Name Autocorrect.

And, oh, BTW, usually, people say THANK YOU when they've been offered good advice, even if it may have been delivered in a somewhat bracing manner. Getting pissy about the tone is likely to mean that serious developers will not answer your questions in the future.

Let me first thank you for this message. Again I do appreciate the time you've taken to reply. With all this knowledge you are throwing around you should write a book. I'm sure that readers will appreciate your sarcastic tone but don't expect me to read it.

Again thanks I'll be sure to recommend this site to all my colleagues.