Page 1 of 2

Collaborative writing - how to merge databases?

Posted: Wed Jan 17, 2007 12:40 pm
by Edwin Sanchez
Hello All,

I already searched the forum and the BE users guide, but maybe I missed something.

I am hoping that BE (9.1) has a merge function. My collaborator just updated my BE database while working on our joint manuscript. I have no idea what new references he added, and he may not be able to recapitulate them all.

Thus, a "simple" merging of the databases that excludes duplicates is what I need. Am hoping against hope that BE can do this.

I know that you can import references from another BE database but there is no option for excluding duplicates.

Also, what is Bookends Pro/Plus?

Thanks, Eddie

Posted: Wed Jan 17, 2007 12:59 pm
by Jon
First, if references were added, they will be at the end of the database (i.e. have the highest numbers), so they should be easy to identify. FYI, you can scroll through the references in numerical order in the reference window, or simply mark them with Refs -> Select -> Select Range. You can export/import the references in question, and then do a Refs -> Remove Duplicates. That should take care of it.

Bookends Pro and Plus are very old versions of Bookends (probably early 1990's). We support export/import from them because we still occasionally get people upgrading from them to the current version of Bookends.

Jon
Sonny Software

Posted: Wed Jan 17, 2007 1:13 pm
by Edwin Sanchez
Thanks, Jon. Will give that a try. Eddie

Posted: Wed Jan 17, 2007 1:54 pm
by Edwin Sanchez
Finding the most recent entries worked pretty well, so thanks for the tip.

But here is my pitch that you please develop a simpler "merge and exclude duplicates" option. I share my database with everyone in my lab (6 people, each working on separate but related projects), yet I am the one that needs to confirm proper content and referencing for each publication. Meanwhile, I am concurrently working on all projects, so that my database simply does not end where the updated database's new entries begin. (Hope I explained that well enough)

Thanks again, Eddie

Posted: Wed Jan 17, 2007 2:17 pm
by daiyi
Edwin Sanchez wrote:
But here is my pitch that you please develop a simpler "merge and exclude duplicates" option. I share my database with everyone in my lab (6 people, each working on separate but related projects), yet I am the one that needs to confirm proper content and referencing for each publication. Meanwhile, I am concurrently working on all projects, so that my database simply does not end where the updated database's new entries begin. (Hope I explained that well enough)

Thanks again, Eddie
It might take longer than you like, but you could use the "remove duplicates" operation under the "Refs" menu. Sorry, I see Jon already mentioned this in his posting above.

Posted: Wed Jan 17, 2007 2:55 pm
by Edwin Sanchez
If import an entire database, I will have to remove over 1,500 duplicates. Does not seem very efficient, when the same algorithm (if that is what you call it) that identifies duplicates could simply be used at the import/merge step.

Eddie

Posted: Thu Jan 18, 2007 6:33 am
by macsailor
Jon wrote:First, if references were added, they will be at the end of the database (i.e. have the highest numbers), so they should be easy to identify.
But if these new references has been added by using the Refs -> Duplicate, the new reference will not be found at the end of the database. It will be found just after the original reference (that was duplicated).

Please correct me if I'm wrong.

Posted: Thu Jan 18, 2007 8:14 am
by Jon
No, that's right. But that won't be a problem for most people, and almost certainly not in the case here.

Jon
Sonny Software

Posted: Thu Jan 18, 2007 4:10 pm
by Shayne
macsailor wrote:But if these new references has been added by using the Refs -> Duplicate, the new reference will not be found at the end of the database. It will be found just after the original reference (that was duplicated).
I just noticed this myself too. Also, replicate as book chapter does the same thing. Would it be possible, Jon, to have duplicate or and replicate as book chapter add the references to the end of the database? Presumably adding a reference by duplication/replication also means that the numbers of all the subsequent references get bumped up one.

I worry that I am losing references when I "merge and purge" my home and work databases.

Shayne

Posted: Thu Jan 18, 2007 4:27 pm
by danzac
This is an interesting discussion. I just add one thing. I think Bookends decision for choosing which duplicate ref to delete is good EXCEPT it does not take into account the notes field. I think it should treat the Notes field the way it treats the Abstract fied according to the User Guide (p.152).

I do like the idea of adding this to the import.

Posted: Thu Jan 18, 2007 4:28 pm
by macsailor
Shayne wrote: I just noticed this myself too. Also, replicate as book chapter does the same thing. Would it be possible, Jon, to have duplicate or and replicate as book chapter add the references to the end of the database? Presumably adding a reference by duplication/replication also means that the numbers of all the subsequent references get bumped up one.

I worry that I am losing references when I "merge and purge" my home and work databases.

Shayne
According to the manual:
If the reference window is in front, the duplicate is placed in the database immediately after the reference. If List View is in front, the duplicated reference(s) are placed at the end of the database. The unique id of a duplicate will be one greater than that of the original (if that unique id is already used, the number will be incremented by one until it is unique). If a static group is selected and a reference in it is duplicated, the new reference will automatically be added to that group.

Posted: Thu Jan 18, 2007 4:37 pm
by Jon
Right. If you are duplicating in the ref window I think it makes sense to add the reference(s) immediately thereafter, so they are sequential. If you're doing this in the List View it doesn't matter, because the list is sorted anyway.

Jon
Sonny Software

Posted: Thu Jan 18, 2007 9:53 pm
by Shayne
Unless I am mistaken, one cannot replicate as book chapter in both of these ways (list view and ref. window). One can only do it from the ref. window, and therefore the reference is not sequential, that is, it follows directly after the edited book reference and is inserted into the order (or one could say, messes up the order). This makes it very difficult to keep track of what references have been added.

Shayne

Posted: Thu Jan 18, 2007 10:13 pm
by Jon
I disagree. I think it makes sense to keep the parent reference and the daughter references (chapters in this case) in sequence.

Jon
Sonny Software

Posted: Thu Jan 18, 2007 10:23 pm
by Shayne
I agree. I did not say it does not make sense. It does make sense, as you say, to keep the parent and daughter references together.

But it does also make it difficult to keep track of additions to a database, which is (or was) the main discussion of this thread.

All of this is just another way of saying what you yourself had said: "First, if references were added, they will be at the end of the database (i.e. have the highest numbers), so they should be easy to identify."

The point is that many references are not at the end of the database and therefore not easy to identify, hence the call for an easy way to merge databases.

Shayne