01-30-2020 03:38 PM
My Windows version of EndNoteX9 was not able to update and when I checked for updates, was told it was updated (even thought it still reported an X9.2 version. I eventually followed the manual update instructions and converted my library. I also neglected to change the automatically open library preferences, so when I went to open EndNoteX9.3 again later, it again wanted to convert my unconverted library and I had to abort. Not sure if it wouldn't have overwritten any changes to my new library if I had continued.
I was also disturbed to find that when I tested what would happen if I tried to open a "converted" library with a pre-X9.3 version of endnote, you only get a warning that there is no .DATA folder, and if you did still continue to open it, it deletes the existing (converted) .DATA folder and then reports that the library needs to be repaired (but of course there is nothing to repair it with).
It is going to be a dangerous upgrade path for our institution, as we try to transition all our Macs and Windows machines, desktops and especially laptops. To ensure our endnote libraries are backed up, we keep them on network drives, which are automatically backed up. We are told to keep nothing on our desktop hard drives. We routinely share libraries and rarely use the cloud solution.
Therefore I predict that there are going to be many corrupted libraries as members who sporatically use Endnote might try to use an older version of endnote to access a library, and forgetting, or never hearing about the upgrade. The error message is uphelpful to the sporatic user. Hopefully, they will recognize the problem, we will be able to restore the library from the backups, when this happens.
Finally, I have not yet discovered how to link my endnote online account to sync with the newly named converted library to the cloud? I am afraid to try, as it is still showing the old file name in the sync preferences.
01-31-2020 07:21 PM
We appreciate your concern. And we're sorry for these current issues.
The Update from EndNote X9.2 to X9.3 is a manual process. While previous iterations of EndNote X9 (the X9.0s and X9.1s) are able to update automatically, EndNote X9.2 is not.
Additionally, the path in EndNote Preferences for automatically opened collections is not going to automatically change. Reconverting an EndNote library, and giving the new conversion exactly the same name as the Old conversion, and OK'ing the replacement of files would overwrite your library. However, you would be warned that you're overwriting an existing file in the process, which should prevent most users from accidentally overwriting their converted library.
Opening a Converted library with an older version of the EndNote software previous to EndNote X9.3 is also quite hazardous to that collection as well. EndNote should issue the warning you indicated, about a missing .DATA folder, giving the user pause before potentially opening that library. Because of this we recommend removing previous versions of EndNote prior to installation of a new version.
It should be noted that Network, and Shared drives are not safe locations for EndNote library files. Being similar to Access files, this article does a good job of documenting why these aren't healthy locations for database files...
EndNote library files are meant to be used from a local drive. So, do be careful they aren't being dynamically backed up while in use, as this could create serious library issues as well.
I also apologize for the current lack of clarity for the Synchronization process for EndNote X9.3.
The way this should work is that when you trigger synchronization with the newly converted EndNote X9.3 version of the library, the Synch process should prompt you to perform a Merge. The answer here should simply be to say "Yes" to the merge, which will then update the online collection to use the converted library.
The converted library will simply take over, as the Online Service is set to expect this to happen with the EndNote X9.3 update.
We are working on a Knowledge Base article to help clarify this behavior, and any users who experience any confusion about, or problems with the process are encouraged to reach out directly to our Technical Support group.
As EndNote now offers support 24 hours 5 days a week, Monday thru Friday, it should be easier than ever to reach us.
Once again, I apologize for our growing pains going to 64bit. Changing from 32bit to 64bit for a database software is much more difficult than it sounds.
Please let us know if you have any other issues that need elaboration of any kind
02-01-2020 12:25 PM
Thanks for your response. I always knew the transition wouldn't be easy, but it seems you weren't prepared for the release or provided any instructions or warnings. Currently beta testing for our institute, and the fact that you still don't allow cloud sharing of more than one library -- it makes it difficult to collaborate with anyone else as we prepare for an institute wide process on both the windows and the Mac platforms. Ugh.
Why not give an option to change the library name rather than a default or a warning that the new one already exists too? Why not force endnote to create a new library name, if it tries to open one that it thinks doesn't have a .DATA file?
I know that developers recommend not using network drives, but I have used the network drive for over 19 years with no hickups, so am not going to change now. Our network drives are backed up, while our hard drives are not. Everything on our work desktops are mapped to network drives. So we will just have to work thru it.
02-04-2020 05:43 PM
I'm not sure that have the answers to the why questions you want.
I can say that, with only an available .ENL file, because most of the overhaul to the EndNote Library structure are the underlying .DATA files/indexes, a missing .DATA folder is going to prevent the EndNote software from being able to tell whether it's the new format, or the old. Whenever possible, users should open the EndNote with the .DATA folder present, as it really contains the bulk of the data for the library. It's not uncommon for an .ENL to have a 0KB file size, as the .ENL file is really a portal into the indexes contained within the .DATA folder.
I can speak to the multiple shared library issue, as it is possible for inter-sharing to help with that.
By which, I mean that each user can share a library.
Sharing is limited to synchronizing 1 library per user. This means that if you have 4 users, potentially you can share 4 different libraries, presuming the users aren't Synchronizing a personal collection.
The library location issues are mostly speed of access, and simultanous access issues.
Used responsibly, and taking care that no other process is attempting to access/copy/scan EndNote library indexes while the library is in use would definitely help to ensure that the library data remains undamaged.
I mention it because many users aren't nearly as responsible with their EndNote library files, and get into serious trouble.
I really can't stress enough that we should be contacted if there are any concerns, or questions, whether or not hold a license for EndNote themselves. When performing any function that may give a user cause for confusion or doubt, we're available in Technical Support to help answer the question.
Monday thru Friday, 24/5 we're available, email, chat, and phone.
And thanks again for your support, and all your help with the forums.