Hi
When I create a new deck and I import data from a csv file I expect to load the notes in the new deck only.
“Update existing notes when first field matches” should affect the deck only which I am about to load. Anything else is misleading and not wanted since when you work with one deck you don’t like to affect other decks.
Load option
“Import even if existing note has same first field” did the trick, so that I could load the deck which I just created with all rows of a csv file, but this is rather confusing.
You can freely move cards between decks, so Anki would have no way of telling where the card belongs to.
There are approaches to deal with this however, one is to add the note id as the first field to cards. Add-ons like this one or this one can be helpful for this approach.
I don’t know how you can move cards between decks. Why should Anki not know where the card belongs to ? If I moved a note from deck A to deck B then Anki knows I want to replace the note in deck B with the version of deck A.
Unwanted side effect of option
“Import even if existing note has same first field”
is that if you import the same csv file twice your deck will consist of double amount of notes. Which is annoying…
Thus the first time you load a deck you use option
“Import even if existing note has same first field”
and the second time option
“Update existing notes when first field matches”
Is this not confusing?
I usually only and always choose Update existing notes when first field matches. Leave it like that for all decks, if you like. That is what I do.
Then every import I do just updates the contents — e.g. if I am changing the card’s presentation, or correcting or tuning the information on a card.
The above implies that I always create the first column as a unique identifier.
Some people, prefer not to create an additional field to use as a unique identifier. They then prefer to allow several different cards with the same first field, as they may be e.g. synonyms. For example: you might have create a card whose Front field is ‘white’ and whose Back field is ‘weiß (adj.)’. Later, you wish to add another card, when you realise that the English word may have another meaning, so you add ‘white’ (same Front field) and Back field ‘Eiweiß (n. masc.)’. Thus you want both cards.
The left-most column is taken as the unique identifier, in the sense that if Anki finds ‘white’, it will want to overwrite the contents. Thus people without an additional unique identifier (e.g. 23546), will wish to choose Import even if existing note has same first field.
hi matta
option Update existing notes when first field matches had the side effect that not all notes (i.e. rows of excel) had been imported. Only option Import even if existing note has same first field loaded all notes.
Again:
it’s counterintuitive that if I import a csv file to a certain deck that other decks are affected as well just because loading is based on notes and not on decks.
As to me it would be nice if there were not option, saying that just this deck is loaded which I am about to import notes. This option should be the default.
wow. Another unwanted side effect is duplicates!
Let me first give some background:
I had a deck A consisting of 544 notes which was based on a csv file A. Unfortunately csv file A lost its UTF-8 format so that I could not use it for import anymore. I had an one month old backup B which I loaded into deck B (it had 488 rows/notes only).
The effect of loading deck B is mentioned above (different loading options needed). In the meantime I built up csv file B and loaded it the first time. The loading of deck B affected deck A as I have now duplicates. Of course I have duplicates if I am going to recreate the original deck A by making a copy of deck A. What I wanted was to build up deck B based on the entries of deck A (the delta of 544-488) by maintaining the input csv file B. In order to do so I exported the missing notes of deck A to a text file which I copied later on to csv file B. The problem is even more intricate as I not only had to reconstruct the missing notes but also I had to mind the fact that in the meantime I modified some entries in csv file A. But which ones? I don’t know. If I am learning deck B (the new learning deck) I would then notice the notes which had been modified. Thus one by one I would correct the modified entries by exporting them from the orginal deck A. That’s why it is so important for me that the original deck is unaffected by loading deck B.
As is mentioned in the manual, duplicate checking depends on the notetype you have selected, not the deck. A single note may have cards that span multiple decks, so it does not make sense to use decks for duplicate checking.
The fact that it’s a possibility is one of the reasons that decks do not make sense as a collision domain. If you want to allow the same content twice without it being marked as a duplicate, you will need to clone the note type and use a separate one for each subject that may conflict.
ok deck does not make sense as a collision domain. Does Anki make sense in the error scenario I described above? The result was a complete mess. The uploads affected the original deck. At the end I reconstructed the input csv file, I had to delete both decks (the original one and the copy), thus I lost the learning history. Really not fun! Now I start from scratch. You know the idea of electronic flash cards came from paper flash cards. There you wouldn’t mind to have duplicates in one or another deck. The deck was the main domain. Nothing else. It would be nice to reconsider the design of Anki in this regard.
hi
thanks for this information. I did a manual backup. However this backup was not reliable because it didn’t contain all notes (probably of the fact that notes are a bigger domain than decks). But even if I could restore the backup I would still meet with the problem to maintain two different copies of one single deck. And to create a copy of notes is counterintuitive to me.