corrupted repliciable database - How to fix? 1

[storer]

When syncronizing 2 replicas, I received 2 error messages, the first said they weren't from the same set (they are!), the second saying that the one database was not a replicated database. When I looked, much to my horror, it had "lost" it's replica status! Out of desperation and "what do I do know?", I tried making a replica of this corrupted database, which it let me do, and it's replica status was back. I went ahead and syncronized, which in hind site I likely shouldn't have done. Now I am realizing that some data did not syncronize. I have 818 entries in the MSyscConflicts table, each with the reason, "Recovered replicable data. This row was recovered from a corrupted replicable database. Verify that the record contents are correct and then reinsert the record or delete this conflict record." The conflict viewer does come up, but it also says "No conflict tables", so i can't fix it there. I totaled the records in each conflict table and they total 818. Any records that have a date that would indicate when the record was created has a date that is later than the last time I syncronized.

My questions are: What causes a replicable database to become corrupt? How do I avoid this?

Can I cut and paste the 818 records in the conflict tables into their corresponding tables? I think some of the records are new, but others are ones that were modified and I will have to decide which is the correct one. I believe most of these records were either created and/or modified by the user I was syncronizing with and will choose her record as the correct one.

After reinserted the 818 records, I'm thinking I should create a new replica and make it the design master and go from there.

It had been 2 weeks since the last time I had syncronized. I've learned I should do it on a more regular basis so if I have a problem, I lose less data! I am an hour and a half away from this other replica...any suggestions other than mailing CDs back and forth???? Can this realiably be done over the internet?

What would have also helped me is if each record had a field that showed the date it was created and/or modified. Then I would know for sure that all these records were created by the corrupted database since the last syncronization. I know how to do the field that would show when it was created. Is there an easy way, from the table not from forms since there are many forms!, that would update this field each time the record was modified?

thanks very much for any help. I need to fix this by tomorrow.

 

[TomCologne]

Maybe you can find out here:

http://support.microsoft.com/defaul...access/content/repl/replfaq.asp#_Toc412801132

Sorry, that's all I got.

TomCologne

 

[sathandle]

You write... ...I have 818 entries in the MSyscConflicts table, each with the reason, "Recovered replicable data. This row was recovered from a corrupted replicable database. Verify that the record contents are correct and then reinsert the record or delete this conflict record."... Possible solution... The operation column in the MSysConflicts tells you if it is a New Record or a record to be added - i.e. operation = 1 Try reviewing this to find the new records to be added.

You write......My questions are: What causes a replicable database to become corrupt? ... My answer: Microsoft and Time

You write... ...How do I avoid this?... I WISH I could answer that (given my past week), but see below... Also, try separating your front end and back end and only synchronizing your back end.

You write... ...Can I cut and paste the 818 records in the conflict tables into their corresponding tables?...
Yes, however, it justs gives you a link to the rowGUID and information as to whether not it was an edit or an add. Use this information to manually reconstruct the database.

You write......I think some of the records are new, but others are ones that were modified and I will have to decide which is the correct one. I believe most of these records were either created and/or modified by the user I was syncronizing with and will choose her record as the correct one. Since there are no conflict tables being listed in Access's Replication Conflict Function Manager the choice of which record to choose as the winning record is yours - manually.

You write...After reinserted the 818 records, I'm thinking I should create a new replica and make it the design master and go from there. ... EXCELLENT IDEA! - Kind of. Create a new blank generic non replicated database and link to your existing tables and then run a make table query to create new tables with all of your data, but exclude the GUID fields (so they are not in your new database twice) and then create a new replica. The only problem with this method is that any Comments listed within your table are lost (or you get the "fortunate" experience of re-typing them all).

You write......any suggestions other than mailing CDs back and forth???? Can this realiably be done over the internet? Send the whole database. (Zip it and e-mail it (if feasible) or transfer it to a central file server or ftp Copy and paste the affected records (find out which ones they are with a Query linking RowGUID and the table, etc.)

You write... What would have also helped me is if each record had a field that showed the date it was created and/or modified. Absolutely - use a general format date field called LastUpdate. Add a hidden control on your forms for the LastUpdate control. In the BeforeUpdate of your Form put the code LastUpdate = Now()

You write...Is there an easy way, from the table not from forms since there are many forms!, that would update this field each time the record was modified? Unfortunately, no. It's grunt work...

You write...thanks very much for any help. I need to fix this by tomorrow. GOOD LUCK!




definition of 'less behind': "not fully caught up, digging out slowly, one-week delay to "The IT hit the fan."

 

[storer]

Thanks for your helpful comments!

The database already is seperated between front and back with only the back end replicated. Only about 20% of the tables contain data that both locations use and require syncronizing. I would like to use your idea of creating a generic database and reconstruct the tables using a make table query...but when I do this, I lose the relationships, keys, lookup row sources, etc.... Any way to keep this from happening?

My plan is to take the back end on a friday, use the Documentor to print "everything you always wanted to know" about the tables, etc..., and use the make table query to reconstruct the back end and only replicate the tables where both locations enter data. If all goes well, I would reinstall it on Monday morning, ready for use. Any short cuts to this? Several years ago I downloaded a program that "Unreplicated" a database but it only worked in Access 97. Have you seen this or something similiar for 2000?

Regarding my problem from last week, I looked at each conflict table individually, figured out which records were new and which were edited and then appended or updated as required. I syncronized this table with the one good, untainted, replica I had left and turned that one into the design master.

I took note of your comment about what causes corrupt databases being Microsoft and time...I've heard that mentioned before and will be vigilant about backups!

 

[sathandle]

Let me know if you find any answers to your later questions from anyone else. I am fresh out of ideas...

To not lose the relationships (a semi-sloppy way of doing it, but possible).

1. Create new db #1 (ndb1)
2. Import tables from replicated db (rdb) (Include relationships)
3. Select query on ndb1 to give just data tables (i.e. not GUID fields)
4. Create new db #2 (ndb2)
5. Link to queries in ndb2 as tables (be sure queries are named qryTableName)
6. Copy and past tables with proper names

Please tell me more about Documentor...

Thanks,
SATHandle definition of 'less behind': "not fully caught up, digging out slowly, one-week delay to "The IT hit the fan."

 

[sathandle]

Disregard my request for more information about Documenter...

OOOOOHHHHHH!!!
AAAAAHHHHHH!!!



I didn't know that even existed (You can tell I am mostly self-taugtht...).

Happy Day!


definition of 'less behind': "not fully caught up, digging out slowly, one-week delay to "The IT hit the fan."