Leaderboard

After giving this just a little bit of thought, here's a solution that could solve the problem. Caveat: I'm suggesting this without knowing the intricacies of the DB structure. Create a new field called DisplayTitle in the table that contains Title. Copy the values of the existing Title field into DisplayTitle. Use this DisplayTitle for searching and display. When a new title is created either by CB or a user, copy that value into the DisplayTitle field as well. If a DisplayTitle needs to be changed, CB changes it and voila, after the next update, the title can be found and sorted correctly. This would require a fairly strict naming protocol using the indicia and year of first publication as the name... something like Metal Men (1993 Series) although even if it gets messed up, it can be easily changed. This solution addresses some of the problems that @Peter R. Bickford brought up in the call yesterday. It doesn't violate the foreign key constraints between Title and Item. It easily allows for renaming the DisplayTitle if the indicia changes between solicitation and publication. There is no requirement to shift data around in the tables and potentially mess up a user's data, since it's simply a DisplayTitle change. I'd love to see something like this implemented. --Walt

I watched the archived livestream last night. I thought Pete's explanation of the problem was clear, but I'm still not sure why something couldn't be implemented (as per Gregory's suggestions above) to make changes and allow users to accept them so we wouldn't have to settle for (and compound) past errors and inconsistencies. I completely understand not wanting to make users move all their inventory after a title correction--I don't want to do that! But can't it be automated, with an option to decline for those with a reason to do so? Their titles would then stand out as "unrecognized" after updates, but currently my titles stand out as unrecognized if I correct them. It seems somewhat analogous to the problem with OneDrive, which is something else that caused me a lot of grief. I eventually got it sorted out, but I spent a few hours going through the information, figuring out what to do, and fighting OneDrive to straighten it all out on my system. (It sounded simpler than it was.) The OneDrive situation was problematic for enough users that they've now devised a way for ComicBase to handle the move as long as you accept the action presented in a dialog box. That would have saved me some grief. Couldn't title and series corrections be handled with a similar approach? Display a dialog box and let the user decide if they want ComicBase to take action for them? From a technological view, the inability to correct titles in software designed for organization (without causing a lot of headaches for users) is a bug that should be fixed. From an archival view, the inclusion and perpetuation of inaccurate information is a strike against the product's credibility. From a capitalistic view, information presented incorrectly or inconsistently sometimes makes buying and selling more difficult, because you can't buy what you can't find. There are multiple good reasons to find a solution to this problem. It doesn't reflect well on an otherwise great product.

I don't fully understand this statement but I believe it follows with my earlier comment about an identifier on each title that was not the title itself. Again, I'm not a database guy but what if the titles as they are now were to become the "foreign key" on some titles? It would only need to be done on titles that are being updated. I seriously doubt we are doing presenting anything that hasn't been looked at before but sometimes this kind of discussion is what it takes to come up with a new solution.

It's a shame that there will be no action on this as there are remedies to fix titles. I was stunned to learn that the foreign key that links titles and items together is the title itself and not a unique identifier of some kind. I understand this is a legacy problem and sympathize but it seems strange that the answer is inaction especially for a product that emphasizes organization. At worst, a new title field could be implemented that is curated by ComicBase following a well-defined standard and that could be activated via a preference. Until then, if ever, I guess we'll have to live with the existing disorganization. ☹️

That's my feeling as well for the same reason.

I haven't moved on to putting my own titles in but moving the FCBD issues doesn't matter much. Thankfully the FCBD issues don't see a lot of action in their pricing. There are a few that have climbed a little but the vast majority stay at "cover price." I get what you're saying though. The lack of pricing would be a complete nightmare especially on long runs. The FCBD issues that make me really crazy are the ones that reprint some or all of a regular issue. The first one I remember finding (or not finding, technically) was Savage Dragon #148. I may even have submitted the FCBD version as a correction a few times. I understand that it has #148 on the cover but it's a FCBD issue. I listed mine as FCBD #2009.

I think it's a great idea, I'm just afraid this is going to die on the vine and I'll be complaining about it again the next time I come across a crazy title.

Instead of creating a new title, porting over a user's existing stock, and then deleting the old title, I think that there might possibly be another way to accomplish the same thing. CB could issue a program update that (for example) looks to see if the user has the title Star Wars (1st series) in their database(s). If they do, the update says something like: "This update will rename your existing title Star Wars (1st series) to Star Wars (1977 series). All of your inventory and issue data will be preserved, only the title will be changed to match to master database. Click "yes" to continue. If you click "no", this update will keep your existing title and create a new, separate Star Wars (1977 series)." For the users that click "yes", the updater will execute the "Modify Title" function to change the series title to Star Wars (1977 series). I imagine that something analogous could be done to change the Media Category for titles as well. I believe that the weekly content updates only import data into your database, so this kind of solution would almost certainly have to be done via a program update.