Fred Slota

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?

Used to record "Legacy numbering". Search for and sort on these new fields and you get a full list of the Legacy run. Could also be used to provide continuous listing of those instances where titles changed but numbering was conserved.

Yeah, I figured it was only for me. I thought posting here would either directly or indirectly get this to the right circles. I'll try in a little bit. Thank you.

Did DF really have Phil Jimenez sign both his and Jim Lee's covers?

So, I searched for ItemDescription = "Variant Cover" and only "Variant Cover", and started adding descriptions to all the variants of an issue (where a scan existed) when there was a Variant with a generic "Variant Cover" ItemDescription. I did a couple of titles and waited to see what would happen. The title "Archie" ended up having quite a few starting at 641/A, and I also did a few in Amazing Spider-Man such as #570, #666 and #691, among others. When I posted these updates, I moved Cover Artists names to the CoverArtist field if necessary, retained any other variant description, and added a cover description in the form "Cover shows xx xx xx xx". I think I used the "cover shows" wording consistently, but I can't be sure since the last updated overwrote my ItemDescriptions, which I wasn't expecting. In the Amazing Spider-Man issues, the descriptions were added for all variants, but my submitted descriptions were placed in parenthesis, and the cover artist references were retained. In the Archie issues, the descriptions were added only for issues where the ItemDescription was empty, and were added using my submitted "Cover shows..." instead of in parenthesis. And all the entries, which already had cover artist names in the CoverArtist field only did not have their cover artists copied into the Item Descriptions when Item Descriptions were added. Oh, and it looks like all my descriptions starting at 700 were dropped, I guess because starting with those issues the ItemDescription started including the cover artist information. So, which is it? Cover descriptions: yes, no, sometimes yes, sometimes no? Cover descriptions in parenthesis or as "cover shows..."? Cover Artists duplicated in ItemDescription, or not, or sometimes yes, sometimes no? I'm also mildly annoyed that among the Archie's I found that the regular and 5 variants of #666, which was a series ender issue, were a 6-panel connecting cover set, and that that detail was dropped along with my cover descriptions.

If we're going to sanction the database madness of repeating Cover Artist in both its dedicated CoverArtist field and the Notes field, can we at least settle on a consistent nomenclature? I suggest "Cover by Joe Smith" or "Retailer Incentive Cover by Joe Smith", as opposed to "Joe Smith Cover" or "Joe Smith Retailer Incentive Cover". This would allow searching for cover artist in the notes field. As a related suggestion, notes about photo covers should use the form "Cover of model Jane Doe" as opposed to "Cover by model Jane Doe", clarifying the difference and allowing for consistent searches.