Peter R. Bickford

Scott: make sure you're running the current build (308x), and that you explicitly choose the Find > Title name or barcode option from the drop-down. If you still have problems afterward, contact support directly at 408-266-6883 Best, -Pete

I'd be curious as to what your experience would be if you booted with all your extensions turned off (other than the Microsoft ones) -- I wonder if you might have something running (anti-virus? security suite?) which is compromising your performance to this extent.

As a heads-up: changed the maximum report page size (before longer reports are broken into multi-section reports) from 2 MB to 1 MB. If you've been having trouble loading reports on your device, try reposting and seeing if the new reports aren't working better for you.

This has been a periodic problem since the contribution points are tracked by your ComicBase ID -- which in turn is tied to your email. If you change emails, you wind up getting lost in the process. As soon as we address some other issues, we'd like to re-jigger these to tie in by your comicbase.com user ID so that the problem doesn't recur. -Pete

Custom fields and checks are carried over by the conversion process to 2020. If you're not seeing the _names_ of the custom items, those are stored in your preferences, and can be reset by entering in their names under Setup > Custom Fields (make sure you're selecting the right collectible--remember, ComicBase 2020 now has multiple types of media it covers, all of which can have their own custom field names). If you're not seeing the _data_ for your custom fields, I'd encourage you to reinstall ComicBase 2017, and double-check that you're converting over the proper database (make sure you see the data in the database you're about to convert). If you still have trouble, please contact support directly at support@comicbase.com, sending them a link to your old ComicBase 2017 database, and noting the exact data you expected to see, but aren't seeing in the converted database. -Pete

Hi Gregg, Looking at the server, I'm seeing a certain number of dropped connections--likely firewall-related. We are testing a new version of the program which switches up the way files are saved to the server and should be less troubled by firewalls--please get in touch with me directly if you (or anyone on this thread) would like to try it out. It's a huge change in connectivity, so I'd like to get as much testing from folks with various security/firewall/networking issues into play on it as possible before we make it part of the general release. -Pete

Give it a go now--it looks like last week's update missed the sync window when we did the database switchover (so the server knew it was expected to be there, but the files weren't present in the right place on the server yet, thus the message you got). -Pete

What behavior, in particular, are you referring to? -Pete

Check three things: 1. Make sure you're running the latest build (I believe it's 20.0.1.2882 currently) 2. Click the Find drop-down and re-select "Title Name of Barcode" 3. Try expanding the top pane by dragging the separator window to make it slightly larger. If none of these restores the auto-search, please send support@comicbase.com a copy of your ComicBase Settings file (from %appdata%\Human Computing\ComicBase\ComicBase Settings.ini) -- we'll see if we can spot the issue. -Pete

When you click an issue, it display issue information; when no issue is selected, it displays title information (including publisher). Since we're re-using the same screen space (and every pixel counts for some users with smaller screens) we're re-using the publisher space for the issue #. If you want to refresh the publisher display, just de-select any issues and the title info will display (ctrl-click any selected issue lines). -Pete

FWIW: It's about 2 second wait on my machine (a 3.6 GHz i9). The bigger difference for this -- and most other things database related -- is that I'm using an NVMe SSD, which takes disk access time essentially to zero in most cases. If you haven't tried them yet (and your motherboard supports them), these are probably the single biggest speed-up for a computer today: https://www.amazon.com/Samsung-970-EVO-SSD-1TB/dp/B07BN217QG?psc=1&SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-brave-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B07BN217QG -Pete

What you're facing is the sheet amount of time it takes to load (Steve, in your case) tens of thousands of items into a list. Short of getting a faster computer, or trimming your comic collection, I'd suggest simply avoiding the issue entirely: use the main title browse instead-- it's essentially instantaneous to load the 500 matching entries to whatever you type into that list. The only time I'd use the Titles browse window is when I explicitly _wanted_ to see the list of all the titles in the database. -Pete

Reports are automatically sectioned into alphabetic sub-reports beyond a certain number of characters (I'd have to look up the limit). Basically, it comes down to " what will load in a reasonable amount of time on a number of test phones running the latest versions of iOS and Android we have here). Fundamentally, you're looking at web page at this point, and it's up to the phone itself to parse the HTML. When the report gets too large, it's automatically broken up into smaller reports, united by the alpha bar at the top of the screen to make it seem like a single report. The smaller reports load faster, but aren't searchable across the entirety of their length (since they're actually several reports). It's a dance to see how much we can get away with showing before every individual user's phone or device can't parse them. The report limit has been fixed for several years now, but if we get increasing reports of trouble, we can move it down. (Choosing less data to report on is also an obvious answer). -Pete

Have a look at build 20.0.1.2874 (just posted). It should address this issue for you. If you have any trouble, please contact me directly. -Pete

Slight correction to what I just told Mark: The dates are now fundamentally stored as YYYY-MM-DD [Not YYYY-DD-MM, as I'd messaged him] As long as SQLite (the new database engine) can get your dates into that format (something it tries to do when converting, but using File > File Tools > Rebuild Lists > Item Information forces the formatting) it should read them on any system, regardless of international settings.