Sometimes the database in the PzDB software partial fails, and one has to add a new database to the mix. This happened this week, as the previous index of the runtime was repeatedly failing to complete an update (in one case on an overnight run). An update run is done to show you everything you just installed in a batch, displayed in PzDB as big elegant thumbnails and ready to drag-and-drop into Poser. PzDB is the only runtime indexer I know of that can do this: you first manually install a saved-up batch of new content, then run ‘RSR to PNG’ on the runtime to be sure you have nice thumbnails, then re-index from PzDB, then use ‘New Items’ or ‘Index date’ to see all the new items in glorious thumbnail-o-vision…
Anyway, the database wasn’t corrupted, just failing to complete a re-indexing run so that newly-added items could be seen. I assume it’s a Microsoft Access thing, on which PzDB runs, rather than a PzDB thing. In such cases one reluctantly but easily makes a completely new index overnight (I’m assuming a runtime the size of a planet, which may take six hours for a ‘first-time’ indexing). Then one starts to tag newly-acquired items on that, while keeping the older indexes in the search mix. That way you retain access to the old tagging work you did on the old indexes. The drawback is that search results then duplicate alongside each other, as you’re searching across two or three indexes that are essentially duplicates of each other. But it’s no great hardship and doesn’t appreciably slow down the search.
Below you see how I search three duplicate Poser runtime indexes, made at different times. Two have been abandoned for tagging and updating purposes, having some unknown glitch that prevents them from updating, but they still work fine as search indexes.
The tripled results…