In sheets, some cells duplicate and overwrite other cells

DEVONthink Feedback
1

I made a sheet in order to list all of my books.

The first three entries are all author entries, with the same name.
All three are sigle line of text, each made separately.

My problem lies with the first two entries.

Basically, I saw three problems.

  1. When I enter an author without entering another one in the second entry, the first entry duplicates itself to the second entry.

  2. If I erase the redondant second entry, the first entriy copies itself again to the second.

  3. Trying to fix that, the second entry once duplicated itself in the first one.

Both using table or form views (I usually use form view to fill entries).

That pretty much blocks my progress.

Is that a feature or a bug; if a bug, when will it be fixed.

Honestly, I am quite shocked to see that such a bug could go unnoticed until now…

2

I can’t reproduce that; can you post screenshots or a screen recording of what you are doing and seeing? Alternatively, a step-by-step instruction (including every step), and I’ll try again.

3

Sure. :slight_smile:

I made screenshots and I will comment them with the steps.

01
011392Ă—850 195 KB

This is what my sheets looks like. The name is “Bibliothèque” and you can see the table view in the bottom panel, with records fixed.

02
021392Ă—850 158 KB

Here, I created a new record in the form view. You can see it has two different authors.

03
031392Ă—850 148 KB

Then, I opened a new blank record, but the bug also happens when just coming back to table view. Here, I went back to table view without entering any information in the new blank record:

04
041392Ă—850 199 KB

Here, you can see that the second author duplicated itself in the first author cell, replacing the previous one.

When I create a new entry with only one author, then it is the first cell that is duplicated into the second cell.

If needed, I don’t mind sharing my database file, since it isn’t encrypted and does not contain any private or crucial information.

1 Like
4

Development will have to assess this, but you should not have multiple columns with the same name.

5

May I chime in with the remark that this kind of data is best kept in a real database? Ninox comes to mind as a cheap product, FileMaker in the expensive end, Airtable… There are probably a lot out there.

Rationale: books and their authors are relations. One would use one table for books (title, # pages, year of publication…), one for the authors (first name, last name, dob, …) and maybe one for the publisher (name, location etc). The book table would then contain the id of the publisher (its record #), not its name. Similarly, a fourth table would combine book and author ids. That

  • prevents repetition of data
  • prevents typos because of the repetition
  • allows for an arbitrary number of authors for each book: no need to n reserve there columns, when in most cases only one is needed. And no problem, if a book has for authors.
  • and most importantly: permits arbitrarily complex queries. Like all books written by a, published by b, in year c.

Sheets are ok for many things. Relational data is not one of them.

1 Like
6

@BLUEFROG
Yes, I guessed so. I am loosely following ISO 690 format, but as @chrillek pointed out, yes, this is database stuff. Now, isn’t DEVONthink a database program?

But the rationale of @chrillek is perfect.

I wanted to learn DEVONthink progressively to, in the end, have this rationale built, especially since many books with have their own article with summary, comments, etc., where the relations would really matter. I would even add the digital version, because I like to keep both printed and digital versions of all my books (printed because it is way better to read, digital for the ease of research and the power of relations building).

Would this goal be beyond DEVONthink?

7

Yes, but it is not a relational database. Loosely spoken, it’s a program to manage unstructured data.
Regardless of DT: a sheet in Numbers, LibreOffice or Excel would not be any better :wink:
In fact, it’s the sheet approach that is not particularly well suited for relational data.

On the other hand, relational databases are not particularly good in handling large blobs of unstructured data like digital books, photos etc.

So a combined approach might work best: have the data in a database with a reference to the book/picture. These can be stored in the filesystem or in DT. On the other hand, DT could store a reference to the database record, perhaps as a link or id in the user meta data.

But this would probably only be worthwhile for a large(r) amount of books. And if you need the search functions I alluded to before. Otherwise – a sheet might be the best compromise. Instead of using three identically named columns, you could have just one „auteurs“, with the names separated by semicolon or comma or slash…

1 Like
8

Thanks very much for the detailed instructions; I can confirm the behaviour you are describing; Jim’s response and my quick experiment would suggest that the identical column names are responsible. I guess the quick workaround would be for you to rename the columns “Auteur un”, “Auteur deux”, “Auteur trois” or some such.

Still sounds like a bug to me, though - i.e. if providing the columns with identical names leads to interactions such as these, then I think I would expect DT to inhibit you from doing so. It’s not uncommon though - if you’ve ever designed forms in Acrobat or similar and used any for of duplication, you might well have been in for a surprise when you thought you had finished. Not that I’m blaming Adobe for that - after the fact it’s all pretty obvious…

9

Thank you all for your answers.

I guess that sums it up: I am not DEVONthink material. :rofl:

Not that DEVONthink is a bad app, definitely NOT. It’s really impressive. But, just, as @chrillek summarized it, what I want to achieve doesn’t seem to really be what DEVONthink is for. Or any application, in fact, so I will go back to relying on my sole brain. :slight_smile: