Fred Slota

Again, you're not addressing what I'm actually reporting... Browse in the main window for Comic Books. Wandering through "Uncanny X-Men, The". Decide "I want to search for currently entered Comic Books". Open Find. Make sure Find is set to search Comic Books. Load my stored search as described above. Run the search. Search results is a list of currently entered Comic Books, sorted. As Expected. Dismiss the search results. return to browsing "Uncanny X-Men, The". In the main window, switch to browsing Magazines. Wandering through "DC Connect". Decide "Hey, let me do that search I just did a moment ago for currently entered Comic Books" Open Find. Find is still set to Comic Books. My search is still loaded. Run the search. Search results is a list of all the issues of the last Comic Book title I had been browsing, "Uncanny X-Men, The" (which, incidentally, does not include an issue that matches my search criteria). Not as expected. This is the essence of what I'm reporting. Why does the search in the second scenario not give the same results as in the first scenario?

Thank you for responding, but I'm not sure that you addressed the point of my question... My question was not "Why when I open Find does it not open searching in the same Media that I was browsing in the Main Window?" My question was "Why does a search for Comics work if I was browsing Comics, but if I decide to search for Comics while browsing Magazines does it fail?", or put differently "What is the point of allowing you to change media in the Find dialog if changing the media in the Find dialog doesn't consistently work?" I'm not pointing out an inconvenience; I'm pointing out that the program presents a feature that doesn't appear to consistently do the thing that it seems it was meant to do.

I enter new books through the ComicBase Mobile app and temporarily add the current date in the Notes field. After import, I can search for the date to produce a sorted list so I can verify that all the books were added, the quantities are correct, I can add the cover scans with drag-and-drop without mucking about with the directories, and then I can delete the date in the notes field. My search, which I have been using for many months now, is: Where: I.[Notes] LIKE "%3/2/22%" Order by: ComicTitles.AlphabetizedTitle, I.[ItemType], I.[IssueNum], I.[Variation], I.[Printing] Today, my additions included a magazine, which did not scan, but I added manually, including the date in the Notes. This lead to some confusion on my part, but has also lead to the observation of inconsistent behavior under four different initial conditions. When I started, the last thing I entered was the magazine, so the main screen was set on the medium of Magazines. When I went to the Find, that too was set on Magazine. Under those conditions, when I perform my Find, an error is thrown over "no such column: ComicTitles.AlphabetizedTitle". After realizing that I was focused on Magazines and that was probably the cause, I changed the main screen medium focus to ComicBooks. When I went to Find, I didn't notice that it was still set to Magazine. When I now performed the Find, there was no error, but the search results switched back to Magazines, returning a list not of Magazines with that Notes field, but a list of all the entries in the Magazine Title that was last viewed. Changing the Main Screen focus to ComicBooks, launching the Find and setting its focus to ComicBooks, my search returns a sorted list of the ComicBooks (without the one magazine) with the matching Notes field. And, for completeness sake, if the Main Screen is set to ComicBooks and the Find is set to Magazines, I get a repeat of the second result, switched to Magazines and a list that consists of all the entries in the Magazine Title that was last viewed. Normally, I would be calling this to your attentions because the program threw an error, but I understand that this is an error of my own making, mucking about with Advanced Find using secret words from magic languages and meddling with forces beyond my understanding. However, in this case, I think the deeper issue is in the fact that I'm getting three different behaviors, not two... Why don't I get two different behaviors, one when attempting to do the Find on Magazines and one when attempting to do the find on ComicBooks? Why does the system throw an error in only one of the four above scenarios, instead of either doing it for two of the four, or for none of the four? Why do I get a successful list of matching Comic Books only when the Main Screen is focused on ComicBooks and the Find is focused on ComicBooks? Shouldn't the selection in the Find window override the selection in the Main window? Actually, the question of "Why" is of lesser importance than the question "Is this the way we want this to behave?".

How do you force run an update?

Is there a way to update the notes field by replace and not by concatenate? Or alternately, is there a way to create a clean database with current Notes fields and port over quantities from an already-populated database?

Update last week, Total Comics 1,000,004 Update this week, Total Comics 1,003,446 3,442 in a week, 178,984 in a year... A little more than 5-1/2 years to 2M?

Is there a way for the screensaver to be aware that Rebuild Pictures is taking place, so that it can avoid attempting to access the database and interfering with the process?

In the words of Douglas Adams, "We have normality. I repeat, we have normality. Anything you still can't cope with is therefore your own problem." 1) Could you please describe the form your problem is taking? 2) Consider the usual generic suggestions - restart your PC, upgrade to the newest release (22.0.0.1576), clear the %temp% folder, check your firewall/antivirus settings.

#1/I is, I assume, the Faded Misprint variant of #1/J, which does not appear to be faded. Is there a better wording for these two variants?

Notes containing "1 in" 199 Notes contain "1:" 172 ItemDescription contains "1 in " 91 ItemDescription contains "1:" 1707 In some cases (I assume preferrably) this is included with "Retailer Incentive" or the like. In some cases this includes additional, inconsistent wording.

Trying to get a consensus on a consistent, information-dense nomenclature... technically, I think it should be 'polyptych', but that has an unfortunate spelling... My preferences, in order "x of diptych", "x of triptych", " x of n-ptych" or "x of n polytych" (4 or more) "x of diptych covers", "x of triptych covers", "x of n-ptych covers" or "x of n polytych covers" (4 or more) "x of n connecting covers" for all. If we're just going with a generic form for all quantities, why use the unusual word.

-ptych, plate, so diptych, triptych as in two plate or three plate... diptych, triptych, tetraptych, pentaptych, hexaptych, heptaptych, octaptych, nonaptych, decaptych. Had to look closer at Earth X (I had laid them out), and boy, are those crossovers from the top 7 to the bottom 7 subtle. But they're there. A tetradecaptych in all its glory.

Connected in a grid.... Detective Comics #1050/C-F, Connecting Legacy four-part in a gird...

diptych, triptych... Are we accepting of longer terms, like heptatych for Earth-X? Or should we used "Connecting Cover" for over three? I just found several (well four times several) reference to a quadtych. (Which, technically, should probably be tetratych) And Quadriptych. -tych does make for a decently unique search term... (Well, excepting that there is a Marvel character named Triptych, apparently), and the resultant term is shorter than "connecting cover x/4" Is triptych specific enough to not need to mention "cover", or should it be "triptych covers"? #1 in triptych with #7/A - #7/C #2 in 'hexatych with #666 - #666/E #3 in "X-Men Mojoverse Triptych"

Forgot to hit send on the above a couple of hours ago. Related titles doesn't mean short titles. I just figured naming the connecting cover would be shorter than listing 3, 4, 5 different titles with issue numbers.

Just found Earth X, where it looks like 0-6 and 7-X each make separate 7-issue connected covers.

Take Batman #467 - #469. And Archie #666 - #666/E. And Robyn Hood: Vigilante #4/E - #4/F Connecting Covers. Usually horizontal, sometimes vertical, possibly in a grid? (have there been any?). Sometimes separate issues without variants, sometimes only certain variants. Sometimes all in the same Title, sometimes runs across separate titles. Ideally, each entry should contain sufficient information to identify: number of covers this item's sequence number all the items involved either simply listing the variants or issues if in the same title providing a unique, descriptive searchable name to the resulting image I think that this information should all be in the ItemDescription field.

Cover scan is uncropped from the full scanner plate. Don't know if my edit would be accepted.

277 Notes with CoA 72 ItemDescription with COA Not all are short for Certificate of Authenticity (East Coast, West Coast, Wizards of the Coast...), but, those which are, I'm submitting rewrites.

[sarcasm] Ohhhhh, and ComicBase allllways matches publisher variant identifications... [\sarcasm]

Might make it clearer going forward, and/or clearer for new users...

I'm not sure what I had been looking at. It's there now. weird.

What happened to this item? Was one of many where I corrected a mismatch in the "Circulation" field vs. what was written in the "Notes" field. Adjustments were accepted everywhere except this item, which appears to have been completely removed? The cover scan, a woman in Arabian garb with a scimitar, had printed in the upper right corner "Robyn Hood: The Hunt #6" "Webstore only exclusive" "Limited to 150"

ABCDE....W?

Why? Isn't this a piece of information that obviously is related to every other piece of information that is in the Item Description field?