Want to know what EndNote has to offer? Try our free series that guides you through the entire process. Read more here.
Do not sync your EndNote library, except by using EndNote's own syncing functionality!!
First, we need to clarify and emphasize that the EndNote library is a database (it is not just a simple text file). And why is this important, well read more below.
The below text is based on the information and quoted from the site codekabinett, we have however changed phrases to fit EndNote specifically. Please also note that we take no responsibility for information on any other sites.
Database files differ from most other files. A tiny change to a single record might result in many different changes to the actual database. In addition to updating the actual, modified record, there might be multiple indexes that need updating, and table storage allocations might need to be extended. Changing a single letter in any record might trigger changes all over the whole database.
Transactions in databases
As if that was not complex enough already, think one step further. Many databases use transactions to write to the records in the database. Several changes to multiple records can be grouped into a single transaction. Meaning all those changes need to be applied or none of them must be applied at all. There is nothing in between. After the transaction completed, it is impossible to reconstruct which changes were done within which transaction. The database itself doesn’t need to know that any more, once it made sure the transaction completed successfully.
However, an external process that synchronizes those changes later (like Dropbox, Onedrive, iCloud etc), would absolutely need to know the individual transactions to keep the data consistent if it would try to sync individual changes below the level of the whole file.
Constant automatic changes to the database file
Now, it should already be clear that you cannot expect the same level of synchronization from most databases. That, however, is only part of the problem. It gets worse.
With almost any other type of application, the data files will be only written to if you actually change something in the file and save your changes. So, any read-only access to the file will not affect its last modified date. Conflicts can only occur between different data writers, but there will never be any conflict between a data reader and a data writer.
That is normally different for databases. In many databases, even if you open and just look at the data without changing anything at all, several files might be written to.
If you execute a query, and that applies to a plain select query already, the database might write some temporary internal data, required to execute the query, to the database file.
The resulting dilemma
Now, combine the two facts elaborated above.
First, database file formats usually are densely packed and do not allow any outside logic to figure out which changes to the file need to be grouped together and applied to another version of the same file to getting both versions in sync.
Second, the file gets updated all the time with important information, as data changes, and with unimportant internal temporary data. It is impossible for any logic outside of the database application to separate these different types of changes.
This creates a scenario in which it is impossible to reliably sync multiple, concurrent versions of such a database file to a consistent state. Any attempt to merge different concurrent changes is doomed to fail and will likely corrupt the database.
Conclusion
The conclusion leads back to the initial simple answer to the question. Do not share any databases on OneDrive, DropBox, iCloud etc with other users.
For EndNote libraries, only copy the library there after you have closed the EndNote application.
Also make sure to make regular backups, read more here.
Read more about where to store your library here.