My sister and I both have RootsMagic 8. I have shared my database with her. Can we both work on it at the same time? One time, it created ‘conflicted’ copies of the database.
RM is NOT designed to be used by simultaneous users.
You will constantly be getting conflicted copies if you try to work in this manner. Even working on the same database not at the same time can be tricky. RM’s database is SQLite, and SQLite databases are designed for one user at a time. Period.
Your sharing tool is probably some sort of cloud backup solution such as Dropbox or Google Drive or OneDrive or I-Drive. SQLite databases such as RM are simply not designed to work with such solutions. You need to either pause your sharing service while you are using RM and resume your sharing service after exiting RM, or else you need to keep your RM database outside of the sharing service and only store backup files in the sharing service.
If you do it by keeping your RM database outside of the sharing service and only storing backup files in the sharing service, you will have to be very disciplined never to open your RM database. Instead, you will have to remember always to restore your RM database when you start an RM session and always to backup your RM database when you end an RM session.
No matter which way you do it and which sharing tool you use, you also will need to be 100% sure every time that the sharing service has fully synced your RM data on both computers. It does no good if the most recent user’s computer has synced with the cloud if the other computer has not.
Obviously, you will have to have some sort of ironclad protocol about who presently has control of the database - some sort of phone call or text message or email - something to communicate that “I’m done and you can start”.
Finally, it’s not common but sometimes two RM users are in the same household with two computers and a local network to connect the two computers instead of a cloud solution. The sync between the computers is faster that way, but nothing else changes. You can’t both work at the same time, and you have to coordinate very carefully about who is working and who is not.
I use a somewhat manual approach to share a RM8 file in a Dropbox folder containing all of my RM files in sub-folders. I have a folder titled “User Checkout box” that contains several text files with file titles like “Mary is working on the database”. When Mary wants to use the RM database, she copies and pastes the text file into the RM folder and then opens the RM file. Then when she is finished she deletes the text file. SO, others are aware that she is working on the database file. If she forgets to delete the text file, Dropbox will display a “conflicted file” message when two or more people have saved to the same file. It’s a manual approach with flaws but it has worked for us for several years. I’ve used this approach with OneDrive and it seems to work. Again it all depends on the discipline of your sharing partners.
Another option 
… 1 of you works on the database on their computer (rather than the cloud) then emails it to the other sister.
Being disciplined is the key. Only 1 can update it at a time so coordinate.
You can color code the people that have been updated, email it, other sister can review and then clear color. When they edit, just reverse the process. You & your sister could each have their own color if you want.
Back up before you start editing with the date attached to the filename.
Use the field “Date Edited” under the people view too.
Can also each have their own database and do any updates but then drag & drop the changed people into a new database. Send to other person and then you can do a Compare Databases to add the changes to their own database. Of course doing a backup prior.
I’ve done this with cousins. Created a mini database for them, they made changes and sent back to me. I would compare with my database and do the updates.
There are two other approaches which require less discipline and cooperation. They are not without their problems, however.
The first is to use TreeShare. Each of you keeps your own private copy of the database and synchs regularly with a private Ancestry tree. The Ancestry tree then becomes the “master” copy where you dectect changes and resolve differences. This provide good tracking of changes and synching. The distadvantage is that there isn’t a one-to-one correspondence between data in RM and Ancestry so you will lose some things going back and forth.
Another approach is to use the ShareMerge. In this scenario, one of you creates a master copy and sends the other a GEDCOM file. They import the GEDCOM file and then send you an exported GEDCOM file with their edits after making changes. You import the GEDCOM file and do an Auto Merge (with a merge of sources and repositories as well). Testing this with RM9, I notice that the merge back had a few problems. Sources are sometimes duplicated in strange ways and the edited people often have duplicate facts.
I tried the ShareMerge feature when it was first introduced into RM decades ago. Indeed, I tried it with great excitement. It sounded great. But in actual use I found it to be totally inpractical. As as already mentioned, one set of edits doesn’t replace the other. Rather, the new edits are merged with the old ones. Reconciling the merged people is a totally manual process, and there isn’t even a way to find out which people have been merged and so need the manual editing.
The duplicate sources are worse than they sound. It’s not just the sources that become duplicated, but the source templates also become duplicated. It’s somewhere between a nightmare and impossible to clean up the mess of the duplicate sources and duplicate source templates.
That was true with all earlier versions. It could be as simple as the stripping of trailing white space in the GEDCOM that would cause a source or fact to be deemed different. That can be helped if the master itself is the result of GEDCOM.
Several “pretty good” solutions have been mentioned, so I won’t repeat them. Any of them can be made to work. The solutions that have been mentioned are about the only solutions that exist. There are no solutions that are “really good”.