I have a patron with Win10 and X8.0.1 who experiences that EndNote crashes without any error message when she try to use file attachment → Attach file for any reference in her library.
Find Fulltext is working ok and attach pdf-files into references without any problem.
Other EndNote functions are working without any problems.
Opening the library in EndNote on our university remote desktop does not cause the file attachment problem. Opening the library in the desktop version afterward still cause the problem.
She has tried reinstalling EndNote several times.
Hello Jan Ove,
The issue may be the location of the library. EndNote is not compatible with any location configured for cloud storage, like Dropbox: http://endnote.com/kb/115635. Also, our engineers do not recommend keeping a library with read and write access on a network drive.
I have used a Network drive for 17 years for my Endnote library, shared with my lab. Since it is absolutely locked if someone with write access opens it, I don’t see how it can be an issue. Maybe other network drives function differently? I know that this is not the case for most cloud storage which allow for multiple users to open and edit and save, which is what causes the problem, as the folders are not tracked/time-stamped correctly for changes and corrupts the underlaying database structure. – I still prefer sharing my library with lab members this way, as it maintains my record number association with records. Which is still a broken feature, as far as I am concerned with the sync system currently “enjoyed” by others. I sync for back up, but not for shared usage.
For guidence on working with EndNote library files, please see the section “7.1 How Not to Share an EndNote Library” in the EndNote Little How-to Book here:
Jason, you can point me to “advice”, but I have real world experience. It has never been a problem on our network drives. All our files are kept on a network drive. That is how our Institutional computers are set up. Our home drive is a network drive, and all our drives are backed up nightly. I believe this to be fake news, whether it is in the “Little Book” or not. Having used Endnote since its inception, and having used a network drive for my library (and the libraries of all our Institute members) since I arrived at my current institute in August of 2000, I beg to differ.
I agree with Leanne. I have also used a network drive to store my EndNote all the years I have been working with and teaching the use of EndNote (12 years). We actually recomend our patrons to use their network drive for library storing instead of the hard drive. This because of the danger of hard drive crashes and the auto back up they get on the network drives)
Are you seriously suggesting that libraries only can be stored on hard drives!? If this is the case, the value of EndNote for our university has to be reevaluated.Network storing is the best in case of security and also allows the patron to use his/her library from different computers/locations (by mapping the network drive).
By they way, the patron in my support case doesn’t use cloud storing and the library was stored on her hardrive.
Jan, I assume you have checked that the client isn’t trying to save it to the program folder, where it might be running into write protection problems?
Leanne, this is not advice I am making up for our customers. This is coming from our Engineering team based on the file structure of EndNote libraries and how they function in network environments. I am glad to hear you have not previously experienced issues. We do recommend keeping the library on a local drive. Our synchronization feature can be utilized as a way of backing up your library.
"Jan, I assume you have checked that the client isn’t trying to save it to the program folder, where it might be running into write protection problems? "
Yes, this was not the case, Leanne.
The number of patrons at our university getting error messages about corrupt library/library is already open (even though the libraries have been fine/not open) has increased since the introduction of Windows 10 and/or X8. Something has changed in the last year making the use of EndNote more unpredictable.
That is disappointing. I have yet to upgrade to X8 or to Window 2010. Since our entire institute is set up to Never use the hard drive – this will impact us going forward - very negatively. At least we are backed up every night but if a corruption occurs during a time when we aren’t using the program daily, it could be harder to identify and retrieve from our back up system.
At the moment I’m not sure what we should teach our patrons in the future. So far the main advice have been to save on server and not on harddisk or cloud services. We have so far not included Endnote online in our courses because of the problems and instability reported previsouly.
On the other side, saving on server have never been a problem for me for the last 12 years.
In my case, it has been for almost 17 years! It is bad software that cannot cope with being on a drive that is networked. In todays research (and I assume business) environment, backing things up is critical regularly (nightly here). That is why our computers are set up to save everything to our home drives which are network drives. Any developer that now decides is not working in the 21st century. This it is a recent change to the advice, for this product, since X8 roll-out, the X7 “little book” recommends not to save it to a “remote network drive” which I interpreted as a cloud equivalent and not a local campus network drive. As I said previously, Syncing is okay, but not perfect, and until it stops messing with my record numbers, well… I am not changing my work flow. Maybe it is time for me to retire, and stop providing support in the forum.
Hello Jan Ove,
We still do not know the root cause of the issue here. We simply do not recommend keeping a library on a network share location. This has not changed between EndNote X7 and X8. Some network environments may be more problematic for saving EndNote library files than others based on the sharing protocols and other aspects of the server file structure. That does not mean this is the cause of the issue. As a method of troubleshooting, my recommendation is to see if the issue persists with a copy of the library on the local workstation. That would help us get a better understanding of the behavior.
If you have not done so already, I would highly recommend contacting our Technical Support team to open a ticket so that we can investigate further: