Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/6/2019 in Posts

  1. Instead of creating a new title, porting over a user's existing stock, and then deleting the old title, I think that there might possibly be another way to accomplish the same thing. CB could issue a program update that (for example) looks to see if the user has the title Star Wars (1st series) in their database(s). If they do, the update says something like: "This update will rename your existing title Star Wars (1st series) to Star Wars (1977 series). All of your inventory and issue data will be preserved, only the title will be changed to match to master database. Click "yes" to continue. If you click "no", this update will keep your existing title and create a new, separate Star Wars (1977 series)." For the users that click "yes", the updater will execute the "Modify Title" function to change the series title to Star Wars (1977 series). I imagine that something analogous could be done to change the Media Category for titles as well. I believe that the weekly content updates only import data into your database, so this kind of solution would almost certainly have to be done via a program update.
    3 points
  2. Here is a first draft of information about the Advanced Find. Let me know if something needs to be added, deleted, modified, or explained better. ******************************************** I believe the database currently used by CB is SQLite. Here is a link to the SQL (Structured Query Language) for SQLite Select. https://www.sqlite.org/lang_select.html Here is a link to the Built-in Scalar SQL Functions https://www.sqlite.org/lang_corefunc.html Because of the limits put on Advance Find, a lot (most) of the SQLite documentation is of no use but it will get you the syntax for the ones you would use. (NOTE: I am supplying these links in case they help someone. Personally, I would use them as examples of how NOT to write a manual. I know what I am doing with SQL and I find these (while accurate) are to read/follow.) ******************************************** The Query functionality in the Advanced Find is limited to just the WHERE clause. You can't control the Select (what columns are returned), the From (the tables involved), or the Group By (used with Aggregate Functions like Sum, Count, Average, etc.). The main reason for this business decision is that every row returned has to be unique to allow them to be updated (changed) individually. Below are sections that are explained in more detail below: Data Types Comparisons Order By Random Notes ******************************************** DATA TYPES: To make it simple, there are just four Data Types (there are actually sub-types for some of these). Text: This is character data and can contain any alpha/numeric/special characters. All Text searches are case-insensitive (ignores case of letters). The constant compare value needs to be contained in single 'tick' marks (double 'tick' marks also work but single is the more standard way). I.[Title] = 'batman' This will return just the one Title 'Batman" as it is an exact match (and shows that Case doesn't matter) Date: This contains Date information. It has to be a valid date. (i.e. Feb 31, 2021 is NOT a valid date). Despite the display of the date in CB as m/d/YYY, the date in SQLite is in ISO standard format of YYYY-MM-DD. This is important because... I.CoverDate = '2020-12-01' will return rows (assuming there is data with that value). I.CoverDate = '12/1/2020' will NOT return any rows. Also it has to be an exact match as all the digits are important: I.CoverDate = '2020-12-1' will NOT return any rows. And like Text, Date constants need to be contained in single 'tick' marks. Number: This contains Numeric information (Integer or Decimal). I.QtyInStock = 2 I.IssueNum = 0.5 I.IssueNum = -1 Binary: This is represented by a Check-box. It is a True/False or 1/0 value. As you can see it has two states. Basically, it translates to 'Is Checked' or 'Is Not Checked'. These are equivalent and will return rows where the CustomCheck2 check-box IS Checked I.[CustomCheck2] IS True I.[CustomCheck2] = 1 And, as you might guess, change to False or 0 to find if a check-box Is Not Checked. ******************************************** COMPARISONS: When using the Where clause, you are normally comparing a Column value to a constant to find something. Some comparison operators are: = Equal To <> Not Equal To < Less Than > Greater Than <= Less Than or Equal To >= Greater Than or Equal To These work as you would expect: I.Title = 'Batman' (Finds Only exact match) I.Title <> 'Batman' (Finds All except 'Batman') I.Title < 'Batman' (Finds All from !Gag! (Harrier) to Baticomic) I.Title > 'Batman' (Finds ALL from 'Batman & Robin (Panini Deutschland)' to '…One to Go') I.Title <= 'Batman' (Same as < but also includes 'Batman') I.Title >= 'Batman' (Same as > but also includes 'Batman') BETWEEN: Syntax is BETWEEN x AND y It is inclusive (meaning the value of X and Y will be included in the results). It is equivalent to using the >= and <= together. For example, these produce the same results: I.IssueNum BETWEEN 5 and 10 I.IssueNum >= 5 AND I.IssueNum <= 10 Either of these will find all IssueNum values of 5, 6, 7, 8, 9, and 10 (assuming only integer values and the value exists). Note: X has to be Less than (or equal) to Y for it to work. This is easier to see if you use the >= and <= I.IssueNum BETWEEN 10 and 5 is equivalent to I.IssueNum >= 10 and I.IssueNum <= 5 There can't be a value that is both Greater than 10 and Less than 5 IN: Syntax is IN (value1, value2,...) Searches for a list of possible value instead of just one. It is equivalent to using multiple = comparisons. For example, these produce the same results: I.IssueNum IN (5, 8, 25, 32) (Note: the values can be in any order) I.IssueNum = 5 OR I.IssueNum = 8 OR I.IssueNum = 25 OR I.IssueNum = 32 Either will find all IssueNum values of 5, 8, 25 and 32. IS: This one is a little different it only has a couple formats: IS True IS False It is mainly used for Binary Data Types. (NOTE: there is also an IS NULL but that should rarely be needed. What is does is check to see if a column contains NULL. NULL is nothing. It is not a 'space' or an empty-string. Rarely, you may need it if a column in CB allows NULL and you need to find them.) LIKE: Syntax is I.Title LIKE 'Batman%' This will find values but uses wild-card symbols to allow finding non-exact matches. The wild-card values are Percent ( % ) and Underscore ( _ ) where a % represents zero to many characters and _ is one and only one character. (NOTE: You can use multiple _ in a row to indicate a specific number of characters.) Examples: I.Title LIKE '%Batman%' will find anything that contains 'Batman' in it (NOTE: Just because % is at the beginning doesn't mean that there has to be something in from of 'Batman' in the Title.) I.Title LIKE 'Bat%Man' will find anything that starts with 'BAT' and ends with 'MAN' and may or may not have other values between them. I.Title LIKE '_Batman' will find anything that that starts with a single character before 'Batman' (NOTE: There has to be a value as this will NOT return just 'Batman') I.Title LIKE '_atman' (one underscore) will return anything that starts with some single character and ends with 'atman' (i.e. 'Batman', 'Catman, 'Ratman') I.Title LIKE '__man' (two underscores) will return anything that starts with two characters and ends with 'tman' (i.e. 'Batman', 'Catman', 'Hitman', 'Ratman') I.Title LIKE '______' (six underscores) will return anything with 6 characters (i.e. '10 Gen','Action', Batman', 'Zordon', etc.) (There are also some NOT versions, like NOT BETWEEN, NOT IN, and IS NOT but NOT logic is best left to Expert Advanced users (or insane ones...). Having said that, they can be useful on occasion so I am at least mentioning them) Boolean Logic Expressions: The Where clause uses Boolean Logic Expressions. Besides the more familiar operators (<, >, =, etc.), it also includes AND, OR, and NOT. They are used to concatenate single comparisons into more complex comparisons. For the Where clause, the comparisons have to end up as TRUE to return rows. With AND, all comparisons have to be True for the Where clause to evaluate as True and return a row. With OR, at lest one comparison has to be True for the Where clause to evaluate as True and return a row. Here is a list to show how this works (the values True and False are being used as the comparisons to emulate the result of comparisons): AND- All have to be True: 'True' AND 'True' evaluates to TRUE , row returned. 'True' AND 'False' evaluates to FALSE, row NOT returned. 'False' AND 'True' evaluates to FALSE, row NOT returned. 'False' AND 'False' evaluates to FALSE, row NOT returned. OR- At least One has to be True: 'True' OR 'True' evaluates to TRUE , row returned. 'True' OR 'False' evaluates to TRUE , row returned. 'False' OR 'True' evaluates to TRUE , row returned. 'False' OR 'False' evaluates to FALSE, row NOT returned. This is also the case for more that two comparisons: 'True' AND 'True' AND 'True' evaluates to TRUE, row returned. 'True' AND 'True' AND 'False' evaluates to FALSE, row NOT returned 'True' OR 'False' OR 'True' evaluates to TRUE, row returned. 'False' OR 'False' OR 'False' evaluates to FALSE, row NOT returned. You can use both AND and OR in the same Where clause but you need to be aware of the Order of Precedence (the order the expressions are evaluated in). AND is processed before OR. To make it easier on you, it is best to use Parenthesis to control the order the comparisons are done. Consider this: I.Title = 'Batman' OR I.IssueNum = 2 AND I.Printing = 2 OR I.Variation = 'HC' I.Title = 'Batman' OR (I.IssueNum = 2 AND I.Printing = 2) OR I.Variation = 'HC' At first glance, the first one is hard to tell what is going to happen. The second one, with parenthesis, is what it actually being done. With the parenthesis, it is easier to see that it will return Any Batman rows, along with Any rows with IssueNum 2 & Printing 2, along with Any rows that have a Variation of HC. While it is still a complex query, it should be easier to understand what will happen. Here is another similar comparison where the only difference is the ANDs and ORs: I.Title = 'Batman' AND I.IssueNum = 2 OR I.Printing = 2 AND I.Variation = 'HC' (I.Title = 'Batman' AND I.IssueNum = 2) OR (I.Printing = 2 AND I.Variation = 'HC') Again, while both will return the same rows, with the parenthesis, it is easier to see that this will return Any Batman with IssueNum 2, along with Any row that has Printing 2 and Variation HC. ******************************************** ORDER BY: There isn't much to say about the Order By clause. It pretty much does what you would expect. Sorts the resutls as requested. The one thing not obvious is you can control the direction of the ordering with ASC (the default value) or DESC. I.Title ASC would sort A-Z and/or 0-100 (ASC is the default and you don't need to add it) I.Title DESC would sort Z-A and/or 100-0 You can mix and match the use of ASC and DESC I.Title ASC, I.IssueNum Desc I.Title Desc, I.IssueNum Desc, I.Variation ASC Keep in mind the Data types when doing sorts. Number and Dates sort as you would expect. Text sorts characters from left to Right. If you have what looks like numbers in a Text field, the sort order would be 1, 10, 100, 2, 20, 200, etc. It would not be 1, 2, 10, 20, 100, 200. The following will sort the results the same way (or at least very similar) to the way CB sorts its display: I.Title, I.IssueNum, I.ItemType, I.Variation, I.Printing ******************************************** [start 2022-01-14 addition] DATA TYPES: Strftime: Strftime allows you to access a date in different ways. The basic syntax is: strftime(format, column-name) Some of the more useful formats are: %m month: 01-12 %d day of month: 00 %w day of week 0-6 with Sunday=0, Saturday=6 %Y year: 0000-9999 NOTE: the format character is case-sensitive. Use upper/lower case as shown. The Month format is probably the most useful as it can be used with both CoverDate and StreetDate. While Day of Month and Day of Week can be used with either, most CoverDate Day values are 1 (excepting items put out multiple times a month) and wont' really get you useful results. While the Year function does work, it is not as efficient as using BETWEEN: strftime('%Y', I.CoverDate) = '2002' takes 23 seconds to process I.CoverDate BETWEEN '2022-01-01' and '2022-12-31' takes 1.75 seconds to process You can also combine this with the BETWEEN function to limit the year ranges for a result. Some examples: Find all items with a day of '15': strftime('%d', I.StreetDate) = '15' Find all items with a day of '15' for years 2000-2009: strftime('%d', I.StreetDate) = '15' AND I.CoverDate BETWEEN '2000-01-01' AND '2009-12-31' Find all items with a day of Wednesday': strftime ('%w', I.StreetDate) = '03' [end 2022-01-14 addition] ******************************************** RANDOM NOTES: What is Item # and why not to use it in Order By: While Item # is the displayed value, it isn't the best field to do Finds with, in most cases. Item # is composed of 4 other columns. They are, in order, ItemType, IssueNum, Variation, and Printing. Item # 1/HC-2 is composed of: ItemType: none used (or regular issue but don't try to find regular issue in ItemType as it is only a display item) IssueNum: 1 Variation: HC Printing: 2 If you try to use Item # in the Order by, it will sort all ItemTypes first. Also, Item # is a Text field and NOT a numeric. You will also get 1, 10, 100-109, 11, 110-119, 12, 120-... This is why it is better to use the various components of the Item # instead of Item # itself when sorting to match CB order: I.Title, I.IssueNum, I.ItemType, I.Variation, I.Printing ====== Use of [] in Column names: Some of you may be curious what the brackets ( [] ) around column names are for (and why I don't use them). If the creator of a Table use a column name with a space (i.e. 'Issue Number') then it is required to enclose it in brackets ( [Issue Number] ) when referencing it so the database sees it has a 'single' name. If there is no space (i.e. IssueNumber), then the brackets are optional. Since the SQL processor adding the columns doesn't know if there are spaces or it, it defaults using brackets, just in case. It doesn't hurt to have them and not need them. However, to me, they just clutter up the display of the query (the less I have to look at and ignore, the better) so I never type them in when I write a query. A similar point could be made for parenthesis. Most SQL processors put way too many, unnecessary parenthesis in their statement. Don't get me wrong. As I showed above, parenthesis can (and sometimes must) be used to make the query either easier to understand or do what you want. But the over-use of them can make for a cluttered query. (Okay, my pet peeve part of this manual is over (for now...)) ====== [end 2021-12-30 addition to cover different Types and Columns] How to use Publisher Title columns in Advanced Find: One thing you may notice, is that only ISSUE columns are available in Advanced Find in the drop-down box. In the old days (pre-CB 2020) there used to be "I" (Issue tables) and "T" (Title tables) where you could access Publisher in Advanced Find. The "I" and "T" were qualifiers to indicate which table a column is in. --- Quick aside (geek alert)... The "I" in I.Title is the qualifier (or identifier) of a Table as defined in a From clause (since the From clause has not been displayed, you can see it directly). It is only really needed if you have more than one Table in the From and you Join them together (i.e. Issue table and Title table). The syntax would look like this: From Issue_Table I inner join Title_Table T on I.Title = T.Title The only thing you need to get from this is that the column Title is in both Tables. Because of this it needs to be qualified when reference (i.e. I.Title for the one int the Title_Table) --- Sadly, with CB 2020, only "I" table columns are (readily) available. However, there is a second way to qualify a column and that is with the actual Table name. So, while you can't select Publisher from the drop-down box, you CAN use it by qualifying it with the actual table name like this: ComicTitles.Publisher = 'Marvel' BookTitles.Publisher = 'Ballantine' MagazineTitles.Publisher = 'Time' ComicTitles.[CustomCheck1] IS TRUE BookTitles.[CustomCheck1] IS TRUE MagazineTitles.[CustomCheck1] IS TRUE NOTE: This is a non-supported feature which may or may not work in future releases of CB. (Maybe HC will make Title columns available in the Advanced Find in the future (hint, hint, hint, please...?) [start 2021-12-30 addition to cover different Types and Columns]
    3 points
  3. Although ComicBase is an amazing program and the defacto standard for cataloging a comic book/magazine/book collection, it suffers from a major defect and that is how titles are created, named, and maintained especially if a title ends and is restarted with a new number one adding it as part of a series. A classic simple example of this is DC Comics's Metal Men, e.g. Metal Men Metal Men (3rd Series) Metal Men (4th Series) Metal Men (Mini-Series) In the example above, Metal Men (Mini-Series) would ideally be Metal Men (2nd Series). However, there is an underlying decision that makes renaming Metal Men (Mini-Series) problematic, as described by Pete, and that is that the title name is used as the foreign key in, what I presume, is the Item table. This defect can make it difficult to locate a specific title, organize titles in order of their publication and often results in additional titles added for titles that already exist. Based on the comments of @Peter R. Bickford in the live stream of 4/13/2022, it seems that it is unlikely to change. I think that's a shame since organization is the major component of a database application. After giving this just a little bit of thought, I think this may be a starting point of a solution that could solve the problem. Caveat: I'm suggesting this without knowing the intricacies of the DB structure and would welcome input. I expect that moving forward with this will not only take time to mull over but to implement as well, but ultimately will make ComicBase an even greater product than it already is. Here's my take: Create a new field called DisplayTitle in the table that contains Title. Copy the values of the existing Title field into DisplayTitle. Use this DisplayTitle for searching and display. When a new title is created either by CB or a user, copy that value into the DisplayTitle field as well. If a DisplayTitle needs to be changed, CB verifies the new display title, changes it and voila, after the next update, the title can be found and sorted correctly. This would allow the implementation of a title naming standard perhaps using the indicia, year, and even the publisher of the title. Something like Metal Men (1993 Series) (DC) The benefit of this is if the standard changes, titles can be easily updated. This solution addresses some of the problems that @Peter R. Bickford brought up in the live stream. It doesn't violate the foreign key constraints between Title and Item. It easily allows for renaming the DisplayTitle if the indicia changes between solicitation and publication of the title. There is no requirement to shift data around in the tables and potentially mess up a user's data, since it's simply a DisplayTitle change. I'd love to see something like this implemented. --Walt
    2 points
  4. Thanks for the catch! We've revved the setup sheet for the scanner here to remove any extra spaces that get inserted: https://www.comicbase.com/Support/CB_Wireless_Scanner_Easy_Setup.pdf The latest build of ComicBase (build 1669) also handles the issue. -Pete
    2 points
  5. Mark, I just did the Friday update. It added 300MB to my dB for all the new Magazine entries. How many of your existing customers have a use for all 5,000 issues of The Daily Telegraph from Australia? This is just bloating the dB and making the updates take a lot longer. I would really, really encourage you to allow all of us existing users to CHOOSE whether we want all the Magazines in our local dB or not. And if you start bloating the dB with 'Books', then please add the same option there too. I subscribe to ComicBase to manage my Comics. Nothing else matters to me.
    2 points
  6. There's also an additional benefit to this approach... it allows a user to define his own display name. It a setting is added to not override DisplayName, a user could easily maintain their own names.
    2 points
  7. That's my feeling as well for the same reason.
    2 points
  8. I think it's a great idea, I'm just afraid this is going to die on the vine and I'll be complaining about it again the next time I come across a crazy title.
    2 points
  9. It's worth noting that the confusion over incorrect and inconsistent titles in ComicBase cascades over to Atomic Avenue as well. So while we ComicBase users can figure things out and learn to work with them as they are, random shoppers using Atomic Avenue may not have a clue. It requires a bit extra to find issues of Donald Duck published by Gladstone, for example, if you don't realize that they will be listed under the title Donald Duck (Walt Disney's...) where the publisher is listed as Dell. I'm not yet selling on Atomic Avenue, but I imagine that more clarity and accuracy would positively affect sales. There are also seemingly random titles that are sometimes assigned to specials and FCBD comics. I've had difficulty finding some of those in the database. My most recent example: I just picked up a copy of a Doctor Who comic book that was exclusively released for the 2015 San Diego Comic Con. The cover logo only says Doctor Who, with 2015 Exclusive San Diego Comic Con International in the bottom corner. The indicia says Doctor Who: San Diego Comic Con Exclusive. I didn't find this among the existing Doctor Who entries, so I added it with the title from the indicia to my database. Only later did I accidentally stumble upon its existing entry: it's under Doctor Who: The Twelfth Doctor as #0. There are a few problems with this: (1) There is no "#0" anywhere on the actual comic book; (2) The San Diego comic does not precede the publication of #1--it came out around the time of #10; (3) Although the San Diego comic features the twelfth Doctor and is related to that series, the words The Twelfth Doctor appear nowhere in its title, unlike the series; and (4) While I might understand an argument for keeping the San Diego comic under this series as a Special Edition instead of #0, other Doctor Who convention specials are listed under their own titles, not as special editions of regular series, so there would still be a lack of consistency. It's a problematic, hard-to-find entry, yet I don't think it can be fixed without screwing up someone else's existing inventory. Publishers have definitely made a mess of things to untangle, and they are not themselves consistent, so discrepancies are bound to occur. I only wish they were easier to correct when pointed out, with some mechanism to transfer users' existing quantities to the corrected title or issue number. I understand that there are technological limitations in place, and circumventing them is well beyond me, but I hope someday this can be worked out.
    2 points
  10. 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).
    2 points
  11. Both the AA and the mobile app functions are pretty important, actually, especially as more items that were tracked in the original "single category" configuration of ComicBase get moved into the Magazine and Book categories.
    2 points
  12. I would put your collection in some kind of order first. It can alphabetical, divided by publisher, divided by character, whatever works for you. Putting the books into CB won't be an overnight process and having some system in place will make it a lot easier to step away whether it is for a day or two or a few months and get right back into the groove when you return. Creating a space is a great thing to do if you can. Setting up on the dining room table is fine until you have to clear it off for dinner. If you can have some little corner to yourself, you can bring in a box at a time and get them entered. Assuming you are using regular comic boxes, whether the long ones or short ones, find a divider of some kind. I taped two backing boards together so they stood out above the books by a couple of inches. Put that divider at the back of the box, behind all of the books, then as you enter books, move them behind the divider. This keeps the books in a single box and in the order you started with while making it clear what has and has not been entered. Bar code scanner or no, if you're having trouble finding a book in CB, you can enter the UPC numbers by hand. It may be slow but if it's only for the random difficult to find book, it works really well. Given that your collecting took off in the 80s and 90s, it is possible that you will have some small press stuff that is either not in the system or is difficult to find. That's a great time to post on the forums to ask where they might be. Don't get discouraged! That's a lot of books to enter and will take time a regular life pushes comics out from time to time. You will get it done!
    2 points
  13. Store variants and online store variants are tricky for us because our solicitation data mainly comes from Diamond and Lunar distribution who don't care them. Thank goodness for our user community who send in data for variants we aren't aware of. Unfortunately, we can have users assign different store variants than others possibly messing up what you might have set yourself for a variant. Not sure there's a good way to get around this, you might want to email support@comicbase.com about a store variant you might have assigned just so we know not override it if a different store variant it comes in.
    2 points
  14. If it is an older comic, the odds that two missing variants would be submitted in the same week are probably low. But for new and fairly recent comics, I can see this as a concern. You can always post on these boards or email support, that gives Marc, Pete, or somebody else at HC to communicate back to you if they will be using a different variant designation than the one that you selected.
    2 points
  15. For deletions, the best bet would be to either email support or post on these boards. The correction submission function from your database doesn't really handle deletions... and deletions often require some sort of explanation anyway, so best to do that via email or public board posting. Generally speaking, go ahead and create the entry in CB and submit. But, if you are entering something that is complicated for some reason, then posting to the boards can generate some helpful discussion. Also, if you can't find a fairly common title, it might be best to post on the boards for assistance before you create an entry. Hypothetical example: you can't find the 1970's Peter Parker, the Spectacular Spider-Man series... posting on the boards will result in somebody pointing out that the title is already in the database as Spectacular Spider-Man, The. Usually the reason behind that occurrence is that the existing cover file is larger than the cover file that you want to upload. The fix is to email the cover to support. Good rule of thumb: if the thing that needs correcting is complex and/or nuanced, please post on the boards! Even though these boards aren't necessarily a high traffic location on the interwebs, there is a pretty good pool of expertise here (from both HC and from CB users) that things often get sorted out pretty quickly. 😁
    2 points
  16. It would be interesting (to me at least) to have a better understanding of how database corrections are processed when they are submitted through CB via the "Submit New or Corrected Data" feature. Filling in an empty field seems pretty straightforward, but what if the correction is deleting duplicate or extraneous information? If someone thinks they have found a new title, is it appropriate to create an entry in CB first and submit it that way, or would that be better for the message board? How much headache do I cause when I upload a correction, immediately realize that I left something out or spelled something incorrectly, and then upload a corrected correction? What happens when I am trying to submit a corrected or larger cover image without any other data changes, and the CB software doesn't ask me for my cover? Did I just submit a "correction" that matches the master database 100%, and does that cause any confusion? Even if not, what is the best way then to get that cover-only correction to the team? I think having a better idea of how the corrections are processed or compared against the master database could help users decide whether it's best to submit something through CB, take it to the message board, or send a direct e-mail, and do so with the minimum amount of confusion for the CB team having to figure out the intent of the user while wading through multiple and duplicate submissions.
    2 points
  17. Not sure if it's feasable, but how about a button for, download covers for all titles in stock/in collection?
    2 points
  18. I can't comment intelligently on the cause of value changes without knowing your collection--all we really do is compute rolling averages on market pricing (a couple million data points each week). That said, one of the features we're looking to incorporate soon is to automatically generate a list of top dollar and percent gainers each week for your collection as it does the update, as well as other reporting tools. Watch for it as we get underway by checking the interim builds page on comicbase.com > support -Pete
    2 points
  19. I love being able to check my collection on the go using the app, but I have a pretty long wish list and a ton of titles in my collection so sometimes I really need to scroll a lot to get to the title I am interested in. A drop-down list allowing you to jump directly to a title or being able to search would make the reports much easier to use. Is this doable?
    2 points
  20. It might be a good idea to add the Mark/Unmark back to the context menu as well. We omitted it since the menu seemed to be getting awfully long, but it'd likely be a good idea to put it back. (You never really know how much some features are being used until you try omitting them from a version!) -Pete
    2 points
  21. I think this falls under the general rule in ComicBase that annuals, specials, etc., are listed under the main title, following the philosophy that if you were looking for them in a shop, you would find them with the main title. It's not my own preference (I'd rather have separate title listings), but I'm learning to live with it. It does make things hard to find sometimes, especially when there are multiple iterations of a series (Justice League, for example) and you don't know for sure which one the annual/special/spectacular is associated with.
    1 point
  22. I'm with you again. If that story hadn't been indexed, would you have ever found it?
    1 point
  23. It's a shame that there will be no action on this as there are remedies to fix titles. I was stunned to learn that the foreign key that links titles and items together is the title itself and not a unique identifier of some kind. I understand this is a legacy problem and sympathize but it seems strange that the answer is inaction especially for a product that emphasizes organization. At worst, a new title field could be implemented that is curated by ComicBase following a well-defined standard and that could be activated via a preference. Until then, if ever, I guess we'll have to live with the existing disorganization. ☹️
    1 point
  24. Randall is correct, changing longstanding titles now makes things problematic b/c existing users' inventory data would be turned into a mess. It's a legacy of a nomenclature decision that was made many many years ago when the re-re-re-relaunching of titles didn't happen and nobody could have predicted that it would become such a commonplace thing. I agree that designating repeated titles by volume # is much more cumbersome as compared to designating them by the year that they launched, and several sites already do this. (Marvel also does this when describing the contents of their trade paperback and hardcover collections.) Long ago (i.e., on the old CB msg boards) I suggested that this problem could be overcome if CB's content updates would (with the user's permission) move existing inventory to newly corrected titles... for example, if CB changed the existing Star Wars (1st series) to Star Wars (1977 series), then the update would give a pop-up window for the user to give permission for their old SW 1st series inventory to all be moved to the new SW 1977 series title. Nothing ever came of it, and my knowledge of programming is insignificant enough for me to have no clue as to whether my suggestion could actually be implemented. But if it could, it would allow CB to do a lot of clean-up that would make the program much more accessible to brand new users.
    1 point
  25. If you're using CB2022, you're running the latest build (22.0.1.1622)? If not, download/install it from your online account here: https://www.comicbase.com/mycb/Registrations.aspx If that doesn't work; please screenshot you're selling settings so we can have a look what you got set.
    1 point
  26. By the way, if you use Add by Barcode, you can check 'Display items after saving', then select all the items, Right-click then from the pop-up menu, use Quick Change to set all the Custom Date column fields to the same date (assuming you got them all at the same time).
    1 point
  27. Thanks for the info, Scott. I didn't know all of that about them.
    1 point
  28. I don't want to have to re-learn the purpose of the established fields. The field names are fine as they are.
    1 point
  29. Maybe support a custom suffix, like 25-local.jpg, which supersedes 25.jpg for presentation (and submission) if it exists.
    1 point
  30. The downside of this decision is that I can't enter nor scan covers for prior issues that I have unless, by some miracle, a first issue is discovered for a title that doesn't have issue numbers nor indicia. The current starting item number of this title in ComicBase is 1 with a cover date of June 1988. I have seen online scans dating as far back as April 1985 (over 3 years earlier). If the current decision stands, I'm basically at a stand still entering this title and, quite frankly, it doesn't give me a lot of confidence going forward when I next hit a similar road block. I've already run into a situation in ComicBase where I had issues of a title (without indicia) whose numbering continued from another title yet was indexed under the original title. I had to research outside of ComicBase to discover what the original title might be -- which seems crazy. It was Super Spider-Man and Captain Britain which were indexed under Spider-Man Comics Weekly because that's where the numbering originated. A note says "Title sometimes known as Super Spider-Man". I don't know how that helps. At any rate, I'm feeling a little frustrated here.
    1 point
  31. Well, THAT only took almost a year instead of "a week or so". Unfortunately, there were some changes to the exported reports used as input data that requered some redesign, and it took waaaaaaaay longer than expected. Shows what shrinking free time will get you... @Fred Slota, I've uploaded the fixed version here: Thanks for your patience, and I hope it fits your needs. Adam
    1 point
  32. While strftime('%Y',I.[CoverDate]) = '2022' does work, using: I.CoverDate BETWEEN '2022-01-01' AND '2022-12-31' is easier to remember and more efficient. Query with function strftime takes 23 seconds to process while Between takes 1.75 seconds. (Ran each query several times and got the same results each time. For those interested, the reason is the function has to be applied to every row before the comparison is made. The Between just has to compare.) PS In case someone hasn't found it, there is an Advanced Find Guide/Manual (work in progress) for those who need a little more information about Advance Find.
    1 point
  33. Until this feature is implemented (if it is), here is one work-around. Do a Find for Qty in Stock >= 1. Once the results are displayed, select / hi-light multiple issues. Right-Click and select Download covers from the pop-up menu. NOTE: There is a limit (not sure what it is) on how many covers you can download at one time. Depending on the number of Items you have, you may have to do this several time.
    1 point
  34. It would be extremely helpful if you would provide instructions as to how to change the folder that Comicbase uses to store the database. My old database file wasn't in my OneDrive folder, but Comicbase kept copying it over into OneDrive. Of even greater utility - when you pop up the warning message about saving into OneDrive perhaps you could have a dialog box that asks the user where they would like to have their database stored. You have options to redirect where the backups should be stored, it should be as easy to setup where the user wants the main database stored. Thanks!
    1 point
  35. If the variants have different paper, usually that also resulted in a different cover price and that would automatically qualify those variants as trackable in CB as separate items. Personally, even if the cover price was the same, I would recommend that the variants be tracked separately if the paper stock is different. Maybe it is worth bringing this up at this week's Livestream?
    1 point
  36. I think the glitch regarding AA searches only turning up comics and not books or magazines has been fixed.
    1 point
  37. you need to fully highlight the issues so any greyed out options become select-able.
    1 point
  38. Try this: Where: (I.[Condition] LIKE 'CGC%' OR I.[Condition] LIKE 'CGC%'LIKE 'CBCS%') AND I.[QtyInStock] >= 1 Order By: I.[Title], I.[ItemType], I.[IssueNum], I.[Variation], I.[Printing]
    1 point
  39. Thanks for that. The problem was specific to counting the results of the "Current value" where conditions weren't NM. Fixed in build 1858, available now.
    1 point
  40. On the "Add by barcode" window, can it be changed - or have added - the total cost of books being added? Currently, it has total cover price. I like to make sure I've got the price paid entered correctly, and being able to compare the cost on my sales receipt to this screen would be *very* helpful. It was there in previous versions, BTW.
    1 point
  41. Strange. Try it this way, bring up a Find window (CTRL+F or click the Magnifying glass icon). Select MyComics in the Find drop-down box. Optional (and should be redundant), click the List Only Items In Stock check box in the bottom left corner. When I run this I get a result of all my comics.
    1 point
  42. It looks like there's a problem with your Crystal Reports installation (a popular reporting module used by ComicBase, numerous other programs). Try running this service pack for it here, then retrying the ComicBase install: -Pete https://www.dropbox.com/s/664lc3oo6iwhqit/CR13SP29Redist32_0-10010309.ZIP?dl=1
    1 point
  43. Find All My Owned With Cover Date For A Year (2017) & Sorted By Value Items Where... I.[CoverDate] >= "2017-01-01" and I.[CoverDate] <= "2017-12-31" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Platinum Age Comics & Sorted By Value Items Where... I.[CoverDate] > "1897-01-01" and I.[CoverDate] < "1938-03-31" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Golden Age Comics & Sorted By Value Items Where... I.[CoverDate] > "1938-04-01" and I.[CoverDate] < "1956-08-31" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Silver Age Comics & Sorted By Value Items Where... I.[CoverDate] > "1956-09-01" and I.[CoverDate] < "1969-12-31" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Bronze Age Comics & Sorted By Value Items Where... I.[CoverDate] > "1970-01-01" and I.[CoverDate] < "1984-12-31" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Modern Age Comics & Sorted By Value Items Where... I.[CoverDate] > "1985-01-01" and I.[CoverDate] < "2050-01-01" and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Comics Of Low Value/Reading Value & Sorted By Value Items Where... I.[Price] < 2.00 and I.[QtyInStock] > 0 Order By I.[Price] desc Find Every Singled Annual Published By Marvel Comics & Sorted By Value Items Where... ComicTitles.Publisher = 'Marvel' AND [ItemNumber] LIKE 'Anl %' Order By I.[Price] desc Find Every Singled None-Variant Comic Published in 2020 Who's Value At Least $50 Greater Than Original Cover Price & Sorted By 2020 Value Items Where... I.[CoverDate] >= "2020-01-01" and I.[CoverDate] <= "2020-12-31" and I.PRICE -I.[CoverPrice] > 50.00 and I.[QtyInStock]>=0 and I.[ItemNumber] not like '%/%' Order By I.[ValueYear4] desc Owned Comics That Have SUPERMAN...Starting Title & Sorted By Value Items Where... I.[Title] LIKE 'SUPERMAN%' and I.[QtyInStock] > 0 Order By I.[Price] desc Owned Comics SINCE 2000 That Have Had At Least A $20 Value Increase Over Previous Year & Sorted By Value Items Where... I.[CoverDate] >= "2000-01-01" and I.PRICE - I.[ValueYear3] > 20.00 and I.[QtyInStock] > 0 Order By I.[Price] desc
    1 point
  44. Thanks Pete. This seems to have fixed the problem for me.
    1 point
  45. Not today...Pete and company are prepping for CB2021's release
    1 point
  46. The Solomon Kane: The Original Marvel Years Omnibus, like many of Marvel's omnibus books, has a regular edition and a direct market variant. The database lists these as Book #1 and Book #1/HC, respectively. To be consistent with other Marvel hardcovers that have regular and DM variants, these should really be listed as Book #1/HC and Book #1/A, respectively. This would require changing the existing Book #1 to Book #1/HC and changing the existing Book #1/HC to Book #1/A. Thanks!
    1 point
  47. When using Quick Change on Fields that contain multiple values is you have to list all the values. For example if the Artist field has J. Scott Cambell, Jack Kirby. If you do a Quick Change to correct Cambell, and just typed J. Scott Campbell, the Artist would just contain J. Scott Campbell. The Jack Kirby entry would be erased. You could try to change it to J. Scott Campbell, Jack Kirby if you just had the one row. But if you have multiple rows, then they would all be set to the same value you entered (either just J. Scott Campbell or J. Scott C\ampbell, Jack Kirby. For the most part, the names with typos only occur a just one or a few rows. The best, easiest way I have found is to just type in the correction manually and then submit the corrections. PS when manually changing, I then to use Paste to insert the missing value as it would cause other names after it to be erased. Or I would copy the rest of the row, type the changes, then paste the info back. Or you could just copy the whole set of values to Notepad, make changes then paste it all back.
    1 point
  48. I had the same problem except I was using 3 custom check boxes, 4 custom fields and one custom date field. Only the custom check boxes retained any information. So I am switching back to the 2017 Archive edition until I can get a couple of days off to try and fix this. But if there's Gary's problem, John Pelszynski's problem as well as mine, maybe there's a bug?
    1 point
  49. Run File Tools->Rebuild Lists Series Information. I think the way CB works now is using 'static' lists (at least this is the easiest way to explain). Just adding a new Title doesn't automatically update these static lists. Rebuilding Series information appears to update them.
    1 point
×
×
  • Create New...