Announcement

Collapse
No announcement yet.

how find orphans?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • how find orphans?

    This is a long-standing and common FAQ - how do I find out what files are "orphans" in AC? It will declare "xxx orphaned files/folders", but how to find out what they are?

    Knowing this would allow one to chase down any broken links, and make sure that the media is nto really lost, instead of just "forget orphans", meaning you would not ever know what got lost, or be able to try to recover it.

  • #2
    As near as I can tell, ACDSee doesn't have that capability. Though to be fair, ACDSee's Optimize Database wizard will get rid of orphaned entries for you if you want. But what if you want to know a bit about the orphans before deletion?

    To my knowledge, NO other DAM product offers that capability. It would seem to me, to add a desirable competitive edge to ACDSee System's marketing efforts.

    I thought about how could ACDSee go about giving us that capability in a hierarchical database? Well to give us the number of orphaned files, all they have to do is add '1' to a running orphan count every time they encounter a database entry that points to a storage location that doesn't contain a photo. But how do they prevent the same orphaned file from adding '1' to the count each time I try to click on that same orphaned file? If I were the ACDSee DBA, I would likely create a binary bit switch called the "Orphan Switch Y/N" So if the program encounters an entry with no valid storage location, it checks the orphan switch for that database entry and only adds '1' to the orphan count if the Orphan Switch is set to "N" and then changes that switch to "Y". This is probably how they do what they do (though clearly, I can't guarantee that)

    If ACDSee were to add a report function that read every entry in the database and saved the name of every entry that had the orphan switch set to "Y", then such a report could be generated. It might be slow, especially really HUGE databases. The report writer might have run quite a while for large databases, but as useful as it would be, orphan remediation isn't likely to be something that has to be done immediately anyway, so even if the report took all night to generate, I don't see that as being a major issue for most people.

    Would a relational database be able to generate this report faster and easier than a hierarchical DB? Yeah, probably. But relational databases are inherently slower in their day to day operation than hierarchical, so the cost in terms of overall Relational responsiveness would gradually begin to take it's toll as the databases got larger.

    And we don't have to read many posts in other forums complaining about the most popular DAM with a relational DB, having speed of operation issues. After 3-4 years of use, without a good DBA taking care of it, the relational DB starts to get a bit creaky and cranky, and we are starting to see that in the Relational DAM products. Basic hierarchical database maintenance is not the arcane science Relational DB maintenance is. The ACDSee "Optimize database" wizard seems up to the job.

    Aside from the cost of development (which COULD be considerable, I can't know that as an outsider, and sometimes the 'simplest things' can be a total PITA), I should think a reportwriter module would be a real competitive asset to ACDSee.
    Last edited by Glen Barrington; 04-01-2017, 06:28 AM.

    Comment


    • #3
      +1 on Glen's suggestion for a report-writer. That would be great! Although a more complex abstraction from a user perspective, I wouldn't mind knowing the schema so I could do some mining or other integrations. (Of course, the database should stay in Read-Only mode!)

      Comment


      • #4
        In View Mode AC precisely 'knows' if a file that's listed is an orphan or not, but AC doesn't tell. E.g. if manage mode displays a set of files of which one or more is an orphan, after selecting all (CTRL-A), AC doesn't allow you to delete them all - it simply doesn't do anything. You have to browse every single file to find out and act accordingly. Same restrictions apply if you try to drag drop the selection to an Explorer window.

        Also if you try to drag drop this selection into another folder within AC with right mouse button pressed, AC will present you a different context menu.

        In all these samples AC does not tell that there are orphans selected and can't do what you want to be done.

        At least in details view (F12) of manage mode, AC should offer a extra column that indicates if a catalogued item is an orphan or not. Also instead of doing nothing, it should return an appropriate message if it can't do what you want.

        [Edit]
        One easy way to find orphans is to view the suspicious items (category or search result) and edit an unused and empty iptc tag. For all files that exist, AC will add the new value. For orphans the tag will remain empty. After sorting the list by this tag all orphans with the empty tag will be on the top of the list.
        Last edited by Emil; 05-03-2017, 12:39 AM.

        Comment


        • #5
          Another option - use a more standard and common database - and then users could easily write SQL scripts for things like this themselves!! :-)

          Comment


          • #6
            Or another approach, use a more common & standard database back-end, then users could write simple (SQL) scripts for anything they needed.

            Comment


            • #7
              Originally posted by guthrie View Post
              Or another approach, use a more common & standard database back-end, then users could write simple (SQL) scripts for anything they needed.

              You can easily open ACDSee database with LibreOffice's Base component. It's treated as dBase database afair.

              Comment

              Working...
              X