Fred Slota

I'm not sure if this was covered in an earlier video, I haven't watched the whole back catalog, but I think a good topic I would like to see a couple of examples of what a reviewer of submissions sees when reviewing submissions and how they process them. A couple of examples would be helpful - a wholly new issue, an edited Title description, an edited Notes, a newly-supplied Cover Artist, etc. What kinds of things are easily recognized, what kinds of things are best warned about ahead of time (and how to bring them up, and to whom).

If something was submitted and approved and now in the Master Database... Shouldn't my copy match the Master database and therefore not get removed from my database when the Rebuild Lists runs on my database? Even if the Rebuild Lists run on my machine pre-update removed my local change, since this was submitted and approved, shouldn't this change be part of the update, and thus be restored to my database in the update? I suppose there could be an issue (no pun intended) if there is a lag between my submission and it getting processed and accepted. The change would not yet be in the Master database, the Rebuild Lists deletes my local, the update does not restore, and my local database had the change removed. But, if it gets processed in the next week, or two, or three, eventually it is in the Master Database, and eventually the Rebuild List or update will restore the submitted change as a now official update. Or, the change is rejected, my local is reverted with the first update, and will never see the change brought back. I can't tell the difference between rejected or pending.

I appreciate that ComicBase has expanded into including Magazines and Books. However, I'm still mainly focused on Comic Books, Can the screensaver include options to include/exclude Books/Comic Books/Magazines?

The pinned topic in this section of the forum left it unclear whether modifications to Title Description were submitted or not.

I moved things from Notes to ItemDescription. They both got reverted. And I didn't run a Rebuild List. It was a regular weekly update. In this case I moved Dynamic Forces references, things that were clearly individual variant specific, and should not have been one-off Notes references. The kind of thing that is exactly what the ItemDescription field was broken off for. I'm going to start using a separate database for some of my cleanup submissions that I will perform updates less often on to preserve some of these changes on my side for longer.

Couldn't see the database Forest for the Notes trees... Notes is the big offender/space-saver, but is not the only repetitive field across variants... Database should be arranged around three tables (Title, Issue and Variant) and not the existing 2 (Title and Issue). Issue would be unique by TitleID, Issue and Type. Issue would include fields like Notes, Storyline, Appearances, Writer, Artist, etc. Variant would be semi-unique by IssueID, Variation (including regular) and Printing. Variant would include fields like Item Description, Cover Artist, Quantity, Condition, Price, etc. The interface could be made to mostly look the same, without letting on at what's happening under the hood. Possibly want to rearrange the Edit Issue window to group Issue fields from Variant fields. Possibly a little tricky to update the grid when an Issue field is modified, in that the change in a single box of an Issue field would need to be reflected in all variants of that issue. Or, the interface could be modified to more naturally reflect the three levels somehow, maybe with Issue grid on the left and Variant grid on the right. Really big reduction in size of the database, Not sure what the performance hits for a three-level data structure vs. a two-level data structure would be.

So, newer issues were added to several of the DC Black Lael titles without this identification in the Notes Field. Rather than updating those issues, I have realized that this is actually the wrong way to go about this. This is breaking one of my database guidelines of minimizing repetition. DC Black Label isn't something that varies variant to variant or issue to issue, it's something that varies title by title, and as such should really be noted in the Title Description. I'm going to go back and remove my previously entered I.[Notes] entries and would like to request a statement of "DC Black Label" be placed in the Title Descriptions for the following titles American Vampire 1976 Batman Day Batman:White Knight Special Batman vs. Bigby! A Wolf in Gotham Batman/Catwoman Batman: Damned Batman: Last Knight on Earth Batman: One Dark Knight Batman: Reptilian Batman: The Imposter Batman: The Smile Killer Batman: Three Jokers Birds of Prey (5th Series) Catwoman: Lonely City Dark Knight Returns: The Golden Child Harleen Harley Quinn and the Birds of Prey (2nd Series) Hellblazer: Rise and Fall Human Target (4th Series) Joker (2nd Series) Joker/Harley: Criminal Sanity Joker/Harley: Criminal Sanity - Secret Files Joker: Killer Smile Last God, The Last God, The: Songs of Lost Children Last God, The: Tales from the Book of Ages Nice House on the Lake, The Other History of the DC Universe, The Peacemaker: Disturbing the Peace Question, The: The Deaths of Vic Sage Rogues (DC) Rorschach Strange Adventures Suicide Squad: Blaze Suicide Squad: Get Joker! Superman vs. Lobo Superman: Year One Swamp Thing: Green Hell Sweet Tooth: The Return Wonder Woman Historia: The Amazons Wonder Woman: Dead Earth

So, I went through the several hundred items in the database with "Dynamic Forces" or "df" in Notes and moved that and their related unique-to-that-variant information from Notes into ItemDescription and submitted all those changes. Doesn't look like they were accepted. And it all was overwritten in my database, both ItemDescription and Notes, when I did the next weekly update. Feeling slightly discouraged on trying to do database cleanup in the less controversial areas. Going to change my strategy for making and submitting changes.

We now have I.[ItemDescription] separate from I.[Notes], where I.[Notes] is meant to have the base description of the issue, while I.[ItemDescription] is meant to have the variant-to-variant description. I.Notes should be identical across #5, #5/A, #5-2, etc. With the existing database structure, that's ideally a lot of repetition, since every variant should have the same I.[Notes], and realistically a lot of inconsistency, since frequently they don't. Suggestion - the current I.Notes field should be moved into its own separate indexed N table. All variants would have identical I.[NotesIndex] values pointing to the same N.[Notes] entry. Replace 1,000,000 I.[Notes] fields with 1,000,000 I.[NotesIndex] and what, 250,000 N.[Notes] fields? That's gotta be a significant reduction in database size...

4,204 ComicBook items in the database with "Limited" in the Notes field 2,391 ComicBook items in the database with "Limited" in the Notes field and 0 in the Circulation field. At a minimum, limited edition runs should have their quantity entered in the Circulation field as well as "Limited to xxx" in the Notes. Better, limited edition runs should have their quantity entered in the Circulation field and "Limited run" in the Notes. Best, a new checkbox should be added to the database and entered next to the Circulation field, I.[LimitedRun], and, and nothing should entered in the Notes field. Additionally, for those who own one of these, a new numeric field should be added, I.[SequentialNumber], for the use of recording which sequentially-numbered issue you have.

The database has separate fields for Number, Type, Variation and Printing, and generates a compound field of Item Number that incorporates all four pieces of information. A similar thing could be done for other fields to generate a compound Description field. To accommodate people with different opinions of what is important, or to accommodate different tasks with different information priorities, these items could be selected from a list, like "Columns to View...", and they would be concatenated together with separating "; ". Or with added identification labels, "(cover artist)". Or with a more data merge, Mad Libs style, "I.Notes (notes); I.[ItemDescription]; I.[CoverArtist] (cover)" And this field should be locally, dynamically generated and not carried as part of the "official database". The key data would be stored in one and only one place, consistent and more reliably searched. Repeated wording related to a field would no longer bloat the database. Display format would be consistent. The database would be smaller.

Yeah, I realized that I hadn't looked into all the credits, but never gathered the will to check. Thank you for the reality check.

Nevermind the above. We eventually hit on clearing out the %temp% folder, which cleared the blockage. Thank you.

I just did it again with "Doctor Who: Empire of the Wolf", and again the Stop button failed to stop the process. Again, apologies. I've been submitting so many modifications recently I just have muscle memory...

Looks like the title, by cover and indicia, should be "Strange Love Adventures"

Selected all issues of a title. Intended to download new covers. Accidentally selected to Send updated data, instead. (Apologies, whoever process these.) Realized instantly what I had done. Saw the dialog with the progress bar had a "Stop" button. Clicked the button. Text changed from "Stop" to "Stopping...". Did not stop. I had pressed it early, probably around 25% done. It nonetheless proceeded to upload all the issues.

So, it looks like the two are one. Sounds like we should remove one and keep the existing annotation in the other. Since ComicBase won't allow an issue number XY, I think it's simpler to keep the issue #6 with the existing note, yes?

I'll start with a question... How are sets implemented in the database structure? Is there a hidden field in I table with set names or keys separated by ';' (since an issue can belong to more than one set)? Is there a set table? A table for each set? A couple of set thoughts... The ability to add a custom set order, or to have a custom set sequence number. This would facilitate using sets to recreate Legacy ordering, or DC triangle ordering, or important storyline ordering. The ability to export and import sets, allowing the sharing of custom sets between users. Not sales or purchases, but the data structure/issue membership in a given set. The ability to search on Set membership field, so as to find items inside or outside of sets with certain qualities.

Still working with Pete, but I just e-mailed him an update with some new observations and a thought that I wanted to see if I could crowdsource some information. I created a new database, with no inventory and no associated purchases, and I could use ComicBase to check for new sales and purchases without complaint. I used ComicBase Mobile to scan and add an issue to the new database, and then ComicBase would generate the complaint when checking for the purchase. I'm running ComicBase 2022, which was my e-mailshows was announced on 12/1/21. I'm running ComicBase Mobile version 2.0.4, which was last updated 5/7/2021. I'm wondering if this version of ComicBase Mobile is compatible with ComicBase 2022? Is there anyone out there who is successfully using ComicBase Mobile to add issues to ComicBase 2022? Is there anyone out there with ComicBase Mobile willing to make a new, blank database with a new database ID and test check for new purchases, scan and add, and recheck for new purchases?

Ah, the weird nooks and crannies one can find when wandering aimlessly down the virtual aisles... Also, I see that there are some levels of redundancy that are more annoying than others... ?

I can kindof see that. I guess most other information isn't prone to post-production changes. It's not like they suddenly announce that the cover for #123/D wasn't done by Joe Smith but by Steve Jones. Ah well, guess it can go for Custom fields or Sets for those who care...

Sorry my mistake in naming the wrong field. But, that was not the point of the post, which was to standardize the freeform text entry so that searches could be more reliably performed.

Under official control, so only allow where it is clear.

I belive the Notes on this issue should rightly be a Title description.

Are these two separate issues?