FrederikBaerentsen/BrickTracker
8
20
Fork 12
Code Issues 16 Pull Requests Actions Packages Projects 1 Releases 10 Wiki Activity

"An error has occured: no such column: bricktracker_parts.spare." after upgrade to 1.4.0 when viewing parts or sets. #148

New Issue
Closed
opened 2026-04-17 01:52:15 +02:00 by commenter · 1 comment
commenter commented 2026-04-17 01:52:15 +02:00
Copy Link
Copy Source

Thanks for the latest update, all the new features look great!
I'm noticing that after upgrading from DB version 20 to 27 post 1.4.0 upgrade, I get this error message when opening /parts/ or any individual set:

An error has occured: no such column: bricktracker_parts.spare.

I'm unable to browse parts or view individual sets as a result. Minifigure views, and the pages individual parts and part lots (though I have no entries for individual parts or lots yet) seem unaffected.

I did use the check database integrity and optimize database features before actually looking at my collection and noting the issue so it's possible one of those new features are related.

I have subsequently added a new set and that does not resolve the issue, either.

Let me know what additional detail I can provide and I will grab and add to the ticket.

Thanks for the latest update, all the new features look great! I'm noticing that after upgrading from DB version 20 to 27 post 1.4.0 upgrade, I get this error message when opening /parts/ or any individual set: `An error has occured: no such column: bricktracker_parts.spare.` I'm unable to browse parts or view individual sets as a result. Minifigure views, and the pages individual parts and part lots (though I have no entries for individual parts or lots yet) seem unaffected. I did use the check database integrity and optimize database features before actually looking at my collection and noting the issue so it's possible one of those new features are related. I have subsequently added a new set and that does not resolve the issue, either. Let me know what additional detail I can provide and I will grab and add to the ticket.
commenter commented 2026-04-17 04:47:25 +02:00
Author
Copy Link
Copy Source

And solved:
BK_PARTS_DEFAULT_ORDER was using the old field names. I don't believe I had ever changed the default, so I think it just retained the old default rather than updating to the new default.

And solved: BK_PARTS_DEFAULT_ORDER was using the old field names. I don't believe I had ever changed the default, so I think it just retained the old default rather than updating to the new default.
❤️ 2
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Out of Scope
Request is out of scope
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
Unraid
Unsupported/Can't help
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
FrederikBaerentsen
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: FrederikBaerentsen/BrickTracker#148
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?