Re: Conflict resolution window no longer opens
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 12 Jan 2007 07:17:20 -0600
"Anne M." <amayer@xxxxxxx> wrote in
news:1168532570.717893.88050@xxxxxxxxxxxxxxxxxxxxxxxxxxx:
David W. Fenton wrote:
"Anne M." <amayer@xxxxxxx> wrote in
news:1168457039.412321.50400@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
I tried your suggestion and the "Conflict Viewer" still does
not pop up, therefore making it impossible to resolve the
conflicts. However, I noticed in my Tables, there were new
table names, such as Owner_Conflict. Is it possible to resolve
using these tables? It only shows the fields from one database
so I cannot determine which field is having the conflict.
Those are the actual conflict tables, yes. You can look at them
manually and figure out what the issue is from that, but you'll
have to look up the corresponding record using the s_GUID, which
may be hidden (to change that, go to Tools | Options and check
SHOW HIDDEN OBJECTS).
Tools/Options/View tab is where I found the box and checked
"Hidden objects", that is how I got the conflict tables to show up
in the Tables list. Is that the option you are referring to or is
there another tab I should look in?
Nope. That's what I meant. I'd forgotten that the conflict tables
are hidden, so you obviously had the correct setting already (I run
with system objects showing at all times, so I forget what's hidden
and what's not).
I did see a "ConflictRowGuid" column in
the conflict tables, however I cannot decifer them. Is this the
same as the s_GUID?
Yes.
An example of the ConflictRowGuid in my conflict table
is {602BDBD3-45C8-4487-9E13-15AD731FBAC8}, this is like asking me
to read a "system dump" (okay, now I am really dating myself).
You can create a query to do it for you, though you can't do a join
from ConflictRowGuid to s_GUID, you can use criteria to do it --
drop the table and its conflict table onto the QBE, then for
criteria you'd want table.s_GUID = table_conflicts.ConflictRowGuid.
I've done this kind of thing many times to work with the system
tables.
This is what I'd do, i.e., manually check the data and determine
if the data in the conflict tables can be discarded. The data
there is the *losing* data. The winning data is in the main
table. If the conflict record *should* have lost, you can just
delete that record. If it should have won, you can copy the data
into the main table. Once you've done this for all the records
you can delete the conflict tables entirely.
I was trying to avoid that but it sounds like the only option.
Thanks for sticking with me.
I've been there myself! And I know it's not fun.
After you've processed the conflict tables, then you have the hard
part -- figuring out why it broke. In the long run, that's more
important than these particular conflicts.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- References:
- Conflict resolution window no longer opens
- From: Anne M.
- Re: Conflict resolution window no longer opens
- From: David W. Fenton
- Re: Conflict resolution window no longer opens
- From: Anne M.
- Re: Conflict resolution window no longer opens
- From: David W. Fenton
- Re: Conflict resolution window no longer opens
- From: Anne M.
- Re: Conflict resolution window no longer opens
- From: David W. Fenton
- Re: Conflict resolution window no longer opens
- From: Anne M.
- Conflict resolution window no longer opens
- Prev by Date: Re: Homegrown synchronization
- Next by Date: Re: Conflict resolution window no longer opens
- Previous by thread: Re: Conflict resolution window no longer opens
- Next by thread: Re: Conflict resolution window no longer opens
- Index(es):
Relevant Pages
|
Loading