Fred Slota

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.

Looks like they were all incorporated. Thank you.

Still happeneing. Could someone please look into my account? I've manually entered the issues into ComicBase, but have them pulled aside, so I can work with either being able to successfully download the additions and correct the totals down, or have the Mobile added items dropped. But I would like to use CBMobile to add new issues when they come out this week. Thank You.

Respectfully, if it wasn't designed to do that, then prevent it from being able to do that. Or redesign it to do that. However, it is very convenient when adding new scans to do so from a list of owned issues without scans. I'll be doing it one at a time from now on.

Okay, I found a real problem from this. I came to a portion of my pile where I had titles with multiple issues to add scans. I added them as a batch, selecting multiple scans and dragging them all at once onto the grid. I had two instances where a scan was copied into the wrong directory. I think the following is what happened. Suppose I was copying 3.jpg and 4.jpg to "Joker". I select Joker #3 in the grid, select both covers, and drag them onto Joker #3 in the grid. ComicBase processes the first scan, copying it to the appropriate directory for the selected row, Joker. Then the grid updates the thumbnail, but finds the first #3 in the grid, which happens to be a different title, say "Death of Doctor Strange" #3. Now, the grid has focused on the row for "Death of Doctor Strange" #3. ComicBase now processes the second scan, and copies it to the directory of the newly-selected row, "Death of Doctor Strange". The end result is that, instead of placing both scans with "Joker", one of the scans has been placed with "Joker" and one with "Death of Doctor Strange". In light of this, I think this issue is more than a cosmetic one. Some adjustment should be made to at minimum maintain the focus on the originally selected row, f not correct the thumbnail update. I make two suggestions. Check for matching issue number AND title when updating thumbnail, or... When drag-and-dropping cover scans, first remember which row is currently selected in the grid. After updating a thumbnail (and before possibly processing additionally dropped scans), reset the focus back to the previously remembered row.

Was going to report "Death of Doctor Strange: Bloodstone" for being mistitled, but... The indicia of the most of the related titles omit the initial "The". According to the indicia, the proper titles are Death of Doctor Strange Death of Doctor Strange: Avengers Death of Doctor Strange: Blade Death of Doctor Strange: Bloodstone (properly entered) Death of Doctor Strange: Spider-Man Death of Doctor Strange: White Fox Death of Doctor Strange: X-Men/Black Knight Strange Academy Presents: The Death of Doctor Strange (the only one with the initial "The", although it is the subtitle - properly entered)

Ah, so if I'm focused on X-Men #15 and drop a file called "10.jpg", it will be placed in the appropriate X-Men folder, but the grid will update the thumbnail for the first #10 in the grid. Gotcha. Would be nice to fix for cosmetic and non-anxiety purposes, but the primary purpose of placing in the right folder, as long as I follow highlight the correct title, it works. Thank you.

I scanned new covers. Rest my Pictures folder to my personal scans. Reset Picture References. Searched for issues with pictures. Highlighted the row for a given issue. Dragged the picture to the highlighted row. All of the time, the picture was placed in the correct folder. Some of the time, the grid of search results appeared to think that the picture went to a different row, moving the focus to that different row and updating the thumbnail for that row. This was disconcerting, in that it appeared that ComicBase was placing the picture in the wrong place.

Added question - If I'm remembering correctly, ComicBase didn't always have the Cover Artist field, so for a long time indicating the variant cover artist in the Notes field would have been unique and useful information, but once the Cover Artist field was introduced, retaining these notes is simply database bloat IMHO.

Still happening for me. Over two days. And yes, I'm getting an error message. Sorry if I wasn't clear, but it's the second paragraph from my original post. I've entered the issues in question manually on the PC, but I still need to merge that with the ones I entered in the app so I can adjust the totals.