J_Cody

OK - I have read the threads and explanations of how "conflicts" occur in SI5 based on the timestamps and if two users sync the same item with timestamps overlapping ranges. Our company currently has 6 designers with permission to update data and we are generating around 30 conflicts per week. Fine.

As Administrator, when I come to MMPD and open the LANSync Conflict Resolution screen, at least 90% of the time the data between the 2 (occasionally 3) records is identical for all the visible attributes, except for "ServerUpdateDateTime" and "MachineName". These two make sense, since 2 users have conflicting update data apparently. But it is hard to see how so many of these are otherwise identical.

So, as an administrator it becomes difficult to choose which item should survive the resolution. "Resolve All" is the automated fix, which seems to take the default record and ignore the conflicting one, but I am concerned that there are perhaps changes that cannot be seen. For example, there is no column in this view to see accessories, which may have been the revision made. I would hate to abandon good accessories that may have been deliberately added, just because I cannot see them in the resolution screen.

Can anyone provide better explanation or advice for viewing, selecting, and managing records in this screen? Thanks.

SenoS

This Conflict interface could certainly use some improvements and I'd be interested to hear more ideas for improving it. Conflicts rarely occur, however, in our SP2 release, they appear more frequently for some users due to a minor bug. We have a Hot Fix that will address this issue. Please contact support and we will email you a link for the download.

J_Cody

Thanks SenoS. I requested the hot fix late today, and will try it. I will try to report back once I run with it a few weeks...

As far as improvements -
#1 - show the user name. There is a field for user in my view but always blank. This would let me contact the user if I need more information on why they changed it, etc. (MachineName can be cross referenced, but is not as easy to compare.)
#2 - show accessory changes if any
#3 - highlight differences between records in a different color or something... or better, only show differences rather than having to scroll across 50 columns.

J_Cody

We ran the hot fix and have been using for a few months since... seems to have reduced the number of conflicts, but I can't really tell specifically other than the quantity seems smaller than previously.

I still think the changes/improvements listed would really help with this interface.

JordanC

Originally Posted by SenoS

This Conflict interface could certainly use some improvements and I'd be interested to hear more ideas for improving it.

We have 5 daily users. Only 3 with master table access. After reading this thread, I realized I haven't had a single conflict since I setup every machine to syncronize on sign in/out.

I use Dropbox, and syncs to every machine 'live' that is connected to the internet. Perhaps this should be implemented with SI.

__________________

Space available for rent.

D-A/V

Originally Posted by JordanC

We have 5 daily users. Only 3 with master table access. After reading this thread, I realized I haven't had a single conflict since I setup every machine to syncronize on sign in/out. I use Dropbox, and syncs to every machine 'live' that is connected to the internet. Perhaps this should be implemented with SI.

How did you do this? Also, do you have all of the job files sync to Dropbox?

JordanC

From SI > File > Sync Product Data on Startup.

All of my "server" project files are on Dropbox, yes.

__________________

Space available for rent.

fryeguy

Have I ever mentioned that "conflict resolution" makes me feel like I'm going to vomit? I would take the sort of conflict resolution required when you don't get along with another person over D-Tools conflict resolution anyday...

Most folks who avoid database conflict resolution altogether, only allow one user to send data up to the server. In a perfect world this would be great but it is not feasible for small companies with rapidly changing data needs.

I would prefer a centralized data structure that allows for storing older versions of data that can be promoted similar to project revisions.