Fred Slota

Yes, but that's overkill. I've not used it before, but I think this is a little more selective, being selective in size of holes and types of issues. I think...

Ah, I thought it would be related to my other issue. And if there are people out sick, I guess that could explain the delay in looking into my ongoing original issue. Get well soon.

Mainly for my curiosity, but what is the background on its value difference from the other 4 first-print variants? I see that there is an odd AtomicAvenue offering of a a VF-NM at $294.99. Does that have an effect on the valuation? Or is that Deadpool card really that much more popular?

Okay, I suspect something deeper is wrong. Since I've been cleaning up my database the last couple of weeks, I've been using manual Updates (not automated with Sidekick) so I can get a report of the unrecognized items. Not only am I still getting the error with trying to integrate my ComicBase Mobile scanned purchases from last week using "Check for new sales and purchases", but my recent attempts to "Check for Updates" continue to say I have the most recently updated content. A new update should have been pushed in the last couple of days, right? The most recently generated Unrecognized items listing is from 1/26/22. Can I please get some feedback?

Yes, exactly. That middle part. And then you go and completely undercut the contrast you set up with your first two sentences and contradict it with your third. Respectfully, now it sounds like you are grasping at straws in attempt to justify or strengthen the argument. Databases are not meant to have redundancy. They are meant to organize information in an efficient and consistent manner. Repeating "cover by" thousands of times makes a database larger, take longer to load, longer to search, longer to longer to rebuild notes, etc. Using a free-form text field allows multiple styles of recording a a piece of information such as "cover by Joe Smith" and "Joe Smith cover" and cover artist Joe Smith" and Joe Smith (cover artist)", making searching and sorting difficult and/or unknowingly incomplete and/or impossible. If you want redundancy against errors, or catastrophes, or personal info versus supposed public info, keep parallel databases or backup databases. Or when attempting to submit modifications for acceptance in the master database, copy the data (temporarily or permanently) in one of the custom text fields. The desire to carry a piece of information officially in two places in a database "just in case" is a really poor justification. Also, wanting printing doubled in Notes or ItemDescription? Why. The book should be identified as -2, or -3; if it's not, that's bad. If "Staring at a screen for long periods of time, it's easily to lose track of things like -A, -3, -A-2, -B-2", then make the "Printing" or "Type" or "Variation" field visible and more prominent in grid view. Having a Note or ItemDescription that reads "Second Printing" provides no information to help you identify how you would tell a second printing from a first printing, no more than having the issue tagged as -2 or -3 does. You tell them apart by notes like "Foil Cover" or "blue background" or CoverArtist "Joe Smith" or "Steve Jones". Cover Artist is useful information. So useful that after, what, 15 years, it was elevated out of the catch-all of "Notes" and given its own separate "CoverArtist" field. Just like a description of what separates different variations from each other was also pulled out of "Notes" a couple of years later and given its own separate "ItemDescription" field. I realize there is history in using this information in the old way, and that the migration of this information out of "Notes" and into "CoverArtist" and "ItemDescription" is inconsistent and incomplete. But we should embrace the change and use it.

To the disappearing Notes, that is troublesome. Isn't there supposed to be an option that retains notes, making rebuilds additive only, to preserve custom notes, for exactly this purpose?

I guess my memory retained what I wanted to hear. Printing is a necessary piece of information to identify a book; should that also be repeated in the Notes/ItemDescription? Annuals are separate items, yet that can safely be kept in its own field. UPC is also useful to differentiate issues; I notice no one is advocating repeating this information in Notes/ItemDescription. I suspect part of this difference of opinion is that the other fields have been separate since the beginning, while CoverArtist was only recently introduced. Earlier, the information was deemed so useful and with no other place to go, it was being entered in the freeform Notes, and now carried over to ItemDescription. We have thousands on thousands of Cover Artists mentioned in Notes/ItemDescription collected over the years, and people have been using it that way for all those years. We've always had cover identification information in the Notes field; that's where we'd go to identify books in the past. Yet I don't see people asking for the cover description information to be retained in Notes while being copied into ItemDescription. I understand Cover Artist is useful information for issue discrimination. For those who find it so, why not rearrange the presented field order to place Cover Artist next to Item Description? I suggest that would make Cover Artist centric folks' lives easier, as it will require less reading and processing of long Notes fields to find this apparently critical piece of information.

Paraphrasing and synthesizing from todays ComicBase TV stream, it sounds like the best-of-both-worlds answer is that the Cover Artist should be in the Cover artist field, while the Item Description field should have enough of a description to identify the cover differences, whether that be "Blue Background", "Foil Cover" or "Variant Cover with Cobra Commander in a dress". No duplication of information, and a description is a faster means to identify different covers than the artist name. This might take a while...

So, more than likely the above "Dynamic Forces" probably should have been moved from Notes to Item Description along with the special cover description.

Is this a comic shop? A cover style? I'm used to seeing it mentioned in descriptions like "Dynamic Forces Variant Cover", but I stumbled across "Witchblade: Shades of Gray" #4/E, where the description indicates "Foil Cover" while the Notes says "Dynamic Forces". Should this instead read "Dynamic Forces Foil Cover"?

I gave 4 separate reasons why operating with unofficial notations in the Notes field produces problems that officially separated entries with a dedicated field would solve. Would it change your mind if instead of thinking of the new field as making a production variant of an issue like Variation or Printing, but rather, as you put it, incorporated into the condition field? Rather than thinking of X-Force 1/A-BG-Card NM vs. X-Force 1/B-UnBg-Card VF, it is thought of as X-Force 1/A NM-Bg-Card vs. X-Force 1/B VF-UnBG-Card? Rather than X-Force #1 having 11 separate variants (5 bagged with different cards, 5 unbagged with different cards, and 1 unbagged without a card), it would have the 5 as-shipped Variants, each with three recognized Condition Variants (bagged with card, unbagged with card and unbagged without card) (Or logically better, 1 with 3 Condition Variants and the other 4 with 2 Condition Variants, as there is no difference between a loose book out of bag and without a card). In the database, there would be a new field, maybe I.[ConditionVariant] or I.[ConditionModifier]. In ComicBase, there would be a drop-down next to Condition with a default of blank and options like Un/Bagged, with/without Card, with/without Poster. In AtomicAvenue, listings would all be under the 5 printing variation, but instead of being separated by Mint, Near Mint, etc., it would be grouped primarily by Condition Variant and then secondarily by Condition, so Bagged Mint through Fine, then unbagged Mint through Fine, etc. Pricing would be tracked separately by ConditioningVariant.

The argument that the platonic ideal of a ComicBase entry is that it describes the condition of the book as initially sold makes sense as rule. Can't have a field that breaks that rule... ...like Condition.

I.[Notes] LIKE "%xxx%", but where xxx is I.[CoverArtist] But given the magnitude of the probable overlap, it's really less for me and more for HumanComputing, to be able find and remove the duplicate [Notes] entries in favor of the CoverArtist field. I would suggest they use the find all to detect the linguistic patterns like "cover by Steve Smith" or "Steve Smith variant cover" to craft more targeted finds to modify the database moving the Steve Smiths to CoverArtist and then stripping them out of the Notes field.

No. No it is not. Redundancy in a database is bad. It represents bloat, inconsistency, inefficiency. Your above description is exactly why this is bad. If there are two places to enter information in a database, it allows you to enter it only in one, only in the other, or in both, meaning you have to make more complicated searches to find everything, and as stated above you have bloat. A quick search for CoverArtist present had over 50,000 instances. "cover by" in Notes or ItemDescription where there was nothing in the CoverArtist field found 415 instances. I'll probably clean those up in the next few days. "cover by" in Notes or ItemDescription where there was something in the CoverArtist field found 38,620 instances. I'll probably not clean those up in the next few days. That's easily cleaned up by Human Computing with direct and full access to the database. There are other forms of noting a cover artist in a free form text description, that are harder or impossible to find. If I had the ability to run the kind of search I enquired about above, I could give a better accounting.

And, since there were several posts while I was typing... I guessed that I left unmentioned in my original proposal, that this new Bagged field would be like the Printing or Variation field, where the default "first print" or "regular", applicable to 99.9% of items, is a blank modifier; a sold-directly-without-a-bag would be blank. Just like "-2" or "-3" indicates second or third printing (separate from a blank implied first printing) and "/A" or "/B" indicates Variation A or Variation B (with or without a separate blank implied regular issue), "-BG" and "-UnBG" would indicate "bagged" or "unbagged" (with or without a separate blank sold-directly-without-a-bag). Yes, if you buy 5 bagged issues, they would be entered under the -BG variant. And if, 2 years later, you open one of the bags, you would deduct one from the -BG count and add it to the -UnBG count. I realize some people think this seems different and unnatural compared to other things in ComicBase, but its not, really... If you buy a Near Mint issue and 3 months later a browsing customer accidentally rips the cover, wouldn't you change the condition field? If you own 3 copies of an issue in VF condition and after a year you send one to be graded, wouldn't you change the original entry to a count of 2 and add a duplicate entry with a different condition or supplemented note?

Can anyone name another genre of collectible that doesn't have a concept of mint-in-the-box? Or that doesn't acknowledge the the qualitative difference between a lone item vs. one with all the original accessories? Maybe it might not make a difference in some cases. I'm sure there are plenty of examples where there is no difference in the market between existing variants... Alternate covers with equal preference, multiple printings with no difference in cover or contents and no real difference in valuation. And yet the database carries them individually by the thousands. In the reverse, maybe it does make a difference in some cases. There probably are issues where a sealed vs. open bag makes a difference, or where a solo book is different from a book with the inclusions. And we won't know, because they're not officially tracked independently. Let me explain the ramifications of not having officially separate items in the master database and instead using an approach with different notes. Take one of my favorite punching bag on this topic - X-Force #1. The original printing was bagged with one of 5 separate, non-bound-in cards, represented by #1/A - #1/E. With no UPC code, either on the cover or the bag. Several of these have items on sale on AtomicAvenue for the unbagged book without the cards. What's the difference between a #1/A without the Cable Card, a #1/B without the Deadpool card, etc? @Peter R. Bickford, I notice that you have a #1/E sans X-Force card up there; how did you decide which variant it should be listed as? Sure seems like there should be a separate item. The #1/B variant with the Deadpool card currently has a value of $11.50, white the #1/E variant with the X-Force card has a value of $3.00, a difference of nearly 4x . Since the book is the same among #1/A - #1/E, then the card must be making the difference. Or is it? Maybe there have been more sales of books without cards as #1/E than there have been of #1/B without cards, and thus the #1/E is artificially low. For that matter, maybe there have been low-value sales for #1/B without the card, and the actual value for a #1/B should properly be higher. Sure seems like there should be separate items. Currently, the official Notes and Item Description for all 5 variants mention that the books have Gatefold Covers and include a card, but don't mention that they were originally sold in a sealed bag. Currently, #1/A has 25 items on sale on Atomic Avenue. I think this is the breakdown... 3 explicitly mention item is bagged. 1 explicitly mention item is unbagged. 4 state or imply they are unbagged by explicitly mentioning there is no card. 9 are in an indeterminate bagged state, but with the card. 6 are in an indeterminate bagged or card state. 1 states, and I quote, "Versus Stryfe Polybag and card bagged and boarded separately With Cable card" So, the majority of those on sale, types 4 and 5, what are you expecting? And for those who say "Contact the seller and ask", why should I have to? Sure seems like there should be separate items. 4. I should hope that people will modify the Notes to reflect the state of their sale. Does everyone do that? If you see a Notes field unaltered from that of the official entry, are you sure it is being sold as described? Sure seems like there should be separate items.

I am not on Slack. Could someone please look into my account and see if there is a way to resolve this? I am still receiving the same error message when attempting to import to ComicBase the issues that I added through ComicBase Mobile last week.

Would like to point out that there are two points to my posting, a general observation and a proposed specific solution. While I understand the difference of opinion on my proposed specific solution, I'm not sure that people are providing feedback on the general observation. ComicBase and Atomic Avenue recognize that there are many ways a given issue of a comic book may exist. Newsstand vs. Direct Market. Main Cover vs. Variant Covers. Enhanced Covers vs. Plain Covers. Multiple printings, which might or might not have different covers. In many of these cases, there are database fields that explicitly record the differences (Cover Artist, Cover Price, Printing, etc.) In modern times, most of the these are accompanied by differing UPC codes. But, in some cases the difference can only be identified by a description in the Notes or Item Description field. But in all the above examples, these differences are reflected by having separate entries in the data base. #1 vs. #1/A vs. #1/CS vs. #1-2. The collector knows that different variants exist, the seller/buyer can have more reliability on what is being looked for or offered, the market history and market pricing can differentiate between low-interest, low-value items and high-interest, high-value items. However, ComicBase/AtomicAvenue does a disservice to its users with its inconsistent and incomplete handling of the various nuances of bagged comics. Regardless of how it is handled, with new database fields or comments in Notes or Item Description, ComicBase should provide a separate entry for each variation. If an issue is sold in a bag, ComicBase should include two entries, one each for the bagged and unbagged form. If an issue is sold blind bagged with different covers or inclusions, ComicBase should include an entry for the bagged form and separate entries for each unbagged cover or combination of inclusions. If an issue is sold unblind bagged with different covers or inclusions, ComicBase should include separate entries for each bagged form and each unbagged cover and/or combination of inclusions. I have a preference of how to support this. But the implementation is almost trivial compared to the need to have this addressed int he first place.

Except it's not the only way. It's one of two ways of doing exactly the same thing. Look in what was "Notes", now "Item Description" for an entry like "Cover by John Smith" or "Peter Davis Variant Cover". Look in "Cover Artist" for an entry like "John Smith" or "Peter Davis" Two ways. Which is one way too many. Really, this should have been taken care of when the "Cover Artist" field was first created and populated. You'll notice that when the "Item Description" field was created and populated, the information was removed from the "Notes" field when it was added to the "Item Description" field. Same thing, only better.

Finished my cleanups and went to use the Hole Finder.... I found my first hole. The .zip file is empty.

Curiously tried I.[ItemDescription] LIKE I.[CoverArtist] in an attempt to find cover artists names in Item Descriptions. Initial returns included numerous instances of blank fields in both. Duh, obviously. Tried I.[ItemDescription] LIKE I.[CoverArtist] AND I.[CoverArtist] > "" and found 4 instances of non-name descriptions in Cover Artist fields. Corrected and sent. Obviously I.[ItemDescription] LIKE "%I.[CoverArtist]%" AND I.[CoverArtist] > "" finds nothing. Is there a way to build a "%xxx%" construction where the xxx is a field value and not the literal text string "I.[CoverArtist]"? I tried I.[ItemDescription] LIKE '%'+I.[CoverArtist]+'%' AND I.[CoverArtist] > "" I.[ItemDescription] LIKE '"%'+I.[CoverArtist]+'%"' AND I.[CoverArtist] > "" And both ran without throwing an error, but found no matching items.

I sent an e-mail a little over a week ago with a corrected cover scan for Bk 1-2, which has not been applied. Currently, the scan is the same as for the first printing. (Same for fourth printing.) I have second printing, UPC ending 00112, with the following scan that would not send since you have a (wrong) scan already. It is similar to that for the third printing, but without the yellow circle mentioning the movie.

They were taken. Thank you.

Looks like this was cleared up. Thank you.

Looks like this was cleaned up. Thank you.