Sage designed it this way, on purpose! Search RDA or sync issues loads of people having the same issues. Highlighted to Sage by many companies over 8 months ago, We rolled back to V27 within a week and that was before Christmas.

Jo Blood said:

This has only happened since v28 and the concept of make everyone a manager 

It's been a disaster for us - and doesn't seem likely its going to be fixed anytime soon

It's not that everyone is a manager but rather that all sites within RDA have been made equal  as this directly address a lot of complexities and limitations that only exist because one site is treat specially Vs others. Access rights do still apply however and there have been changes in the v28.1 release so the options to force a push or a pull are correctly controlled by an access right (which was always the original intent). The v28.1 release has been out for a few weeks now so if you don't already have it make sure to do an update check in the software. Once upgraded make sure you have the appropriate permissions set for your users based on what options you want them to have in the situation of a sync conflict:

Hope that helps.

Still illogical, if you have 5 people working you can lose 4 peoples worth of data. 

Or even simply 2 people working you still lose 1 persons data. How is that acceptable?

Its an indefensible failing. Cost us £1000's which is why I keep pulling you guys on it.

It is entirely based on logic. If the software hits a situation where there is a data conflict for some reason all that can be done is to take the data from one side or the other. The software cannot make an independent decision as to which data is more important than the other so we present the choice to the to the user. Regardless of which side 'loses' in the conflict resolution a backup is created of data that is being overwritten, so data is never entirely lost. We did consider turning the losing data in to an archive instead of a backup as this might be a little easier to view the data, but that has bigger ramifications including adding a significant overhead to the data size and therefore chew up your bandwidth, so that idea was parked in favour of a simple backup.

It is worth noting that that in terms of design this conflict resolution is not intended as the 'norm'. Data conflicts are not typically expected in normal usage (if you are seeing these frequently then worth speaking to our support team to see if an underlying cause can be determined). Rather it is intended as way to recover from a situation where the sync has somehow gone wrong, or where users deliberately choose to work offline and then come back online later on but other user may have changed data in the meantime.

A logical fix to a problem which was intentionally created!  My logic is obviously different to yours.

Connection loss and therefore data conflicts should never be the "norm" however real world conditions are not ideal.

Ofcom do a report which shows the number of disconnections daily for consumers. The "norm" is more than 1 x 30 second drop per day, so a 5 user system would see a "norm" of 5 drops in 24 hours. The sage system relies on 100% connectivity to not lose data then Sage is not working to the "norm" conditions but to ideal conditions.

UK Home Broadband Performance - Technical Report (March 2021 data) (ofcom.org.uk)

Sage does not even need a 30s drop to stop functioning, it requires a momentary drop at the wrong moment. 

Indefensible.

Andrew Cooke said:

A logical fix to a problem which was intentionally created!  My logic is obviously different to yours.

A problem was not intentionally created though. Sync conflict is a fundamental concept that exists with any form of data sync regardless of the technology used or specific implementation details.

Andrew Cooke said:

Connection loss and therefore data conflicts should never be the "norm" however real world conditions are not ideal.

The trouble here is you are assuming that Internet drop outs are the cause of data conflicts, but this is not actually the case. Certainly if your Internet connection dropped and you then deliberately chose to continue to process data offline you can have conflicts when you come back online if other users have also been making changes at the same time. However that would be a deliberate user choice as the software will prompt if you try to make changes but the RDA service cannot be contacted.

Andrew Cooke said:

Sage does not even need a 30s drop to stop functioning, it requires a momentary drop at the wrong moment. 

Indefensible.

An internet drop out, even a prolonged one, does not inherently cause a data sync issue. The problem arises when 2 users make conflicting changes outside of a lock i.e. one or more users working offline. That leads to a situation where one of those changes must be taken over the other(s) so a conflict resolution prompt is the correct thing to do in that case.

As I say, if you are seeing sync problems after a brief drop out then please speak to our support team to see if an underlying cause can be determined.

"A problem was not intentionally created though. Sync conflict is a fundamental concept that exists with any form of data sync regardless of the technology used or specific implementation details."

Yes it was!

The fundamental changes Sage made to change V27 to V28 created the problem so you came up with a solution, Sage knew people would lose data before it was launched.

Your comment is below from another thread: 

This is actually by design. Sync issues can occur for numerous reasons, including ones that are beyond our control e.g. a temporary loss of Internet connectivity on one client and 'offline' changes are made to the data whilst other clients remain connected and also makes changes.

With the improvements to RDA in v28 if a client on RDA encounters a sync issue that cannot be automatically recovered from the user will be offered a choice on how to resolve it. You can either choose to keep the changes currently in the cloud and potentially lose changes you might have locally, or to keep your local changes, push those to the cloud and potentially lose changes there. Choosing the latter option means that any other clients connected to the data via RDA will need to 'rebase' to ensure they can correctly get back in sync.

The reasoning behind this is that we can never know what data is the most important, and therefore which to keep. One set of data has to lose to be able to resolve the sync conflict. No one site has any more priority than any other one anymore so the best (only) thing we can do is ask you which side should win. This change in approach to site priority meant we could open up significant usability improvements for clients using RDA, including the ability to upgrade data from any site and the ability to use any connected service from an site - both significant limitations in v27 and earlier.

It's worth noting that the conflict resolution dialog that is presented explains the repercussions of either choice, and a backup is generated before the data is 'rebased' (in either direction) so it is always be possible to access any data that may have been 'lost' as a result of the conflict resolution. Also, if you have reasons why you do not want certain users to be able to force their changes to be pushed to the cloud as part of conflict resolution we added an explicit permission for this so you can remove this from those users and in the conflict resolution dialog they will not be offered the choice to keep their changes and can only chose to download from the cloud. A backup of the local data will still of course be created before the rebase happens.

Andrew Cooke said:

"A problem was not intentionally created though. Sync conflict is a fundamental concept that exists with any form of data sync regardless of the technology used or specific implementation details."

Yes it was!

These sage sync issues were created by the fundamental changes made to sage v27 to update to V28. See below this is your comment, you knew people would have to choose which data to "lose" before V28 was even launched.

Remote Data Access sync issue - General Discussion - Sage 50 Accounts and Sage 50cloud Accounts UK - Sage City Community [https://www.sagecity.com/gb/sage-50-accounts-and-sage-50cloud-accounts-uk/f/sage-50-accounts-and-sage-50cloud-accounts-uk-general-discussion/177440/remote-data-access-sync-issue/452554#452554]

The changes in v28 did not create the problem. It always existed previously and v28 has not changed this fact in the slightest. The difference is that in v27 and earlier one site was always denoted as the main site and there was a very blunt, and frankly naïve, rule in place that in the case of encountering a data conflict the main site's data was forcibly accepted as the conflict winner and all other sites would lose data with no choice and no opportunity to backup or otherwise recover the lost data.

With v28 we removed the concept of main sites as it was a very problematic one and simply too limiting for most users. An example of a significant limitation we had was that if you wanted to upgrade you could only do this on the main site. The Covid pandemic, and some of the restrictions that came about because of it, highlighted just how problematic the man site design could be for users. We had many reports of cases where users simply could not physically access their main site due to office closure and travel restrictions so were unable to perform the upgrade. This meant they were blocked from accessing new features and bug fixes that they wanted in later versions of the software, as well as problems of exchanging data with their Accountants when the Accountant themselves had upgraded. There were also issues such as only being able to access or use certain features of the software if you were on the main site. Extremely limiting.

The v28 changes to remove the concept of main directly addressed these problems and limitations, offering a significantly more flexible setup. As there is no longer a concept of main the 'main site always wins' rule for conflict resolution we previously had could no longer apply. This is the point where you are suggesting where we have deliberately introduced a problem. However this is not the case. As mentioned above the issue already existed but was handled in a manner that was never a great design in any event as it essentially meant you would silently lose data in the event of a data conflict. The design now is therefore that, as we can never know which data is more important, we prompt to ask which one should win and ensure a back up is performed on the losing data so nothing is ever entirely lost. To be honest we really should have been doing this even back when we had the concept of main as just because a site is designated as main it does not mean that the data entered at another 'secondary' site is less important or easier to recover/re-enter.

I would again stress that data conflicts are not expected to be a frequent occurrence. If you are seeing repeated data conflicts then please speak to our support team to see if an underlying cause can be determined.