I exported my collection to XML.
Created a new Collection.
Imported that XML file to the new Collection.
Almost all fields and data looks good, but why are the “lastmodified” and most importantly the “dateadded” fields ignored (they’re both being filled in with the specific date/time I performed the import “today”)? And how do I make it respect those data fields from the XML file - the dateadded value is very important to me.
Indeed, that is intentional as that is “the day they are inserted into your collection” when you import from XML.
I can see and understand why you would want these to be imported from the XML - but I have no workaround.
That being said, what exactly are you trying to do? What is the goal here?
That is a story. It comes back to my three previous posts.
I have manually updated my 700 plus author’s pick list to be proper mixed case, and proper first name last name or last name first name display name and sort name respectively. But it doesn’t propagate to my CLZ mobile nor my cloud.clz.com book list.
if valuation can’t be done accurately based on the old nine digit ISBN numbers, I want to convert my thousand or two old ISBNs into the 13 digit ISBNs using an ISBN convert algorithm I found on the internet, but not one at a time within the desktop app.
For all of that combined, I was hoping to export my entire collection to XML, edit the XML file with some global replace automation for everything I want done, and re-import it to a new collection. Then delete my CLZ mobile data and the cloud.clz.com data, and resync from my new desktop app collection to refill both of them.
(FYI I wish that CLZ would just take valid nine digit SBNs from the ISBN field and convert the automatically using that algorithm to be a 13-digit ISBN for the purpose of the valuations. In fact it would be nice to have two fields, one where you can enter the literal nine digit SBN that is on old books, and a 13-digit ISBN field that can be derived from that as needed.)
Note that I do not have the web-based CLZ app. Does that offer a kind of import/data load that will allow me to continue what I’m trying to do?
Well the CLZ Web app does have an XML import, so you could try it at least?
I’m not aware of 9-digit ISBNs though?
ISBN 10 vs ISBN 13:
Book Collector automatically converts the ISBN-10 to an ISBN-13 by putting 3 numbers in front of it. The check digit (last number) which is a sum of formula of all numbers in front of it, changes, because 3 numbers are added.
However, the ISBN-13 number is still unique and means the same as the ISBN-10 number. There is no way to change that back to ISBN-10 with Book Collector, simply because it’s not necessary.
If you try searching one of your ISBN-10 numbers within your own collection, Book Collector should come up with the ISBN-13 number because it converts it again.
The last number of an ISBN-10 is a “check digit”. It is a number that is generated by a formula of all 9 numbers in front of it.
The last number of an ISBN-13 is also a “check digit”. Because the formula (and length of the ISBN) is slightly different, the last number will change from the ISBN-10 number.
Sorry, yes, 10 digits.
Hmm, I’m unsure about that built-in conversion. I made sure the valuation report was up to date and then I went in and started changing some 10 digits to 13 digits, and for every change I made the valuation changed for those books only. I thought that meant that having the 13 digit in their manually made a difference.
The ISBN 10/13 conversion actually happens if you type ISBN10 in the Add Books screen, and then search our Core - it doesn’t happen in the edit book screen though - could that be it?
Okay that’s an interesting and probably relevant distinction.
I assume a CLZID value means my book is “linked with the Core”, so let me focus on my CLZID=0 entries, specifically the CLZID=0 where ISBN is not blank (273 records):
27 have an ISBN13 which I’m almost certain I manually typed in AFTER the book had been added to my database (either finding it in the ebook content, or converting the existing ISBN10 I had recorded for paperbacks)
38 have an ISBN10 (with hyphens). These ones would be either values I typed while adding the initial record to my database, or they were imported to CLZ desktop in 2009 from a text/excelCSV file that I was using before CLZ. I’d have to do some digging in old excel files to be able to make the distinction between those two possibilities (i.e., my real life “dateadded” value)
2 ISBN9
135 ISBN8
70 remaining “ISBN” values ranging from 7 to 3 digits
If CLZID=0 means it’s not linked to the core, and replacing the non-ISBN13 number with an ISBN13 number doesn’t link it to the core, how do I link it to the core?
I found the link to core feature in the menus. This is the first time I have used that since I bought the product in 2009! It worked. I selected two books with CLZID = 0, where they are actually two copies of the same book. I left one of them with the ISBN 10 number including hyphens, and the other one I changed to the proper ISBN 13. They linked to the core with no problem and now have a proper CLZID, And also the valuation on them is identical. I should be able to repeat that in batches with all of my other ISBN 10 books, now that I know how.
With a quick proof of concept done, I think I now have a solution for maintaining my dateadded values, without having to edit each record one at a time. User defined values - I have now created my own dateadded field within that feature. I am making good progress on a shell script that will massage a full database XML export, by plugging in the user defined values chunk of XML code for every book, and it will copy the existing date added field into my new user-defined value dateadded field. That way when I create a new database on my desktop, and import the massaged XML file, my own userdefined dateadded field will preserve the value I used to have in the formal dateadded field. After I perform that XML import to a new database, I can clear the database from my CLZ cloud and from my CLZ mobile, and resync both from scratch from my desktop.
Thanks for that suggestion, much appreciated. Unfortunately it appears to me that the built in “Date Added” field isn’t one of the available source fields for copying.
Indeed, Date Added and Date Modified are internal, non changeable fields. They are updated when a book is inserted (import, add, whatever) for Date Added, and Date Modified whenever you do any edit for that book, right in the software itself.