Zum Hauptinhalt gehen

Can I share catalogues?

Kommentare

14 Kommentare

  • Walter Rowe
    Moderator
    Top Commenter

    The catalog has to exist in a place both PCs can see it, or you have to sync the catalog across PCs.

    I use a portable drive for my files. I sync the catalog from internal SSD to the portable drive, then when I plug the drive into another machine I sync the catalog from the portable drive to the internal SSD of the second machine. When done, I sync from the second machine's internal SSD back to the portable drive, and back on the first machine I sync from the portable drive back to the internal SSD.

    Could you do something similar with your NAS? Maybe create a folder on the NAS for your catalog and use that folder to sync the catalog across PCs?

    • Work on PC 1
    • Sync PC1 internal drive => NAS folder
    • Sync NAS folder => PC2 internal drive
    • Work on PC2
    • Sync PC2 internal drive => NAS folder
    • Sync NAS folder => PC1 internal drive
    • Work on PC 1

    The NAS folder also makes for a great FULL copy backup of the catalog should you lose one or both PCs.

    0
  • Alan Sh

    I'm being thick - it's the 'open' command. It works fine as long as all the drive letters match across the two PCs. No synching needed.

    Alan

    0
  • Ian Wilson
    Moderator
    Top Commenter

    Also, it's necessary to close the catalog on one computer before opening it on the other. It won't let you have the same catalog open from two different places at once (because that is a recipe for disaster).

    Ian

    0
  • Alan Sh

    That's fair enough. I don't normally leave C1 open if I'm not using it.

    Alan

    0
  • Jerry C

    Ian notes Capture One is programmed to allow access to its database to only one user at a time. This is their choice, not an inherent limitation of relational databases. Limiting access has nothing to do with licensure since the access point would still need a license.  

    Relational databases (like SQL) can be programmed to be accessed by a defined number of users of a database on a server. They do this by locking objects so that only a single transaction (user) can modify the object at a time. Locking can occur of the entire database, a record, a field or other object. This is essential for inventory, medical record, and other systems that have multiple simultaneous users. The easiest way to prevent write access to an object by more than one user is to lock the entire database.

    So, when Capture One opens a database, it applies a writelock to the entire database. If you copy a Capture One database while it is open, you will not be able to open the copy because the writelock file (seen by examining the database package) is still in the package until the database is closed. The writelock is not itself locked and can be deleted while the database is opened. This might allow access to the database on a server from multiple computers, but because Capture One is not programmed to protect simultaneous access to objects, simultaneous use of the database by multiple users could result in multiple users attempting to make changes to the same object and might well lead to corruption due to the limitation of Capture Ones design. Capture One should lock access to the writelock file while the database is in use to prevent this.

    Capture Ones database structure could use many improvements to enhance performance and making databases accessible on a server to multiple users could be useful as long as the owner of a database could control access. Multiuser access makes databases somewhat less efficient and add complexity, so Capture One would be better off improving the performance of the single user database before adding something more complex. 

    0
  • Alan Sh

    Thanks Jerry. Many years ago I was doing database design over networks, so I am aware of write locks. It's a shame that C1 does a database writelock and not a record writelock, but as long as I ensure the DB is closed on one PC before opening it another, I should be OK.

    Cheers

    Alan

    0
  • Walter Rowe
    Moderator
    Top Commenter

    I'm guessing the CO database design is taken straight from its origin in MediaPro (which originated as iView Media Pro). It is meant to be a single user database. I'm guessing that a row locking designed app would suffer some performance vs single user database locking using a simple write lock file.

    0
  • Ian Wilson
    Moderator
    Top Commenter

    I'm guessing the CO database design is taken straight from its origin in MediaPro 

    If only!

    Media Pro's catalog had features that Capture One lacks.

    Ian

    1
  • SFA
    Top Commenter

    I'm not at all sure that the nature of a catalog as a database, in the context of the option in C1, could be made into a viable database shared by 2 or more users at the same time.

    Maybe of ported to some sort of server based database system every possible use situation could be catered for, but with mass selections of "records" possible and then mass changes data fields to be calculated and applied I could see a lot of issues and a lot of confusion among users unless some very strict rules could be applied in the code and the outcomes understood by the users.

    0
  • Walter Rowe
    Moderator
    Top Commenter

    Ian Wilson

    Media Pro was a single-user tool like C1's catalog.

    I used it in all its incarnations: iView Media Pro, then Expressions Media (Microsoft), then Media Pro (PhaseOne).

    0
  • Jerry C

    Up to now, my comments were related to the possible, but I can see from other's comments it would not be practical.

    A relational database should be able to lock all selected objects so that only one user can edit them. This works well in an inventory or other database that works with facts. A database oriented toward image editing deals with opinions regarding the choice of edits. 

    The bigger issue is that multiple users could still make changes unknown to others unless the users had a means of real time communication or less usefully, these changes were flagged. Without a way of sharing intent, one could make edits another user did not like. Locking all the records you don't want touched just creates another problem of interoperability. 

     

    0
  • Ian Wilson
    Moderator
    Top Commenter

    Yes, I used it briefly. What drove me to using a Capture One catalog instead of only sessions was the demise of Media Pro. But when I made the transition I assumed that the catalog function in Capture One would be like Media Pro, and in some respects it wasn't. Then I assumed, or at least hoped, that they would beef up the catalog functions in Capture One after retiring Media Pro, but they didn't. As far as I can tell, they are much the same now as they were then, with minor exceptions.

    Two big differences: With Media Pro, you could search more than one catalog at the same time. And I found the handling of keywords in Capture One rather clunky. In Media Pro, as I recall, you added keywords and could filter to find images with a particular keyword in the same place. But in Capture One, you add them in one tool, and filter in another tool. The really annoying thing about that is that the filter tool doesn't match the order in which keywords appear in the keyword tool. (I have several keyword libraries, with hierarchical keywords notably for wildlife, arranged by species, but also places, and people, and activities. They appear in a logical order in the Keyword Library tool which does not match at all the order in which they appear in the Filters tool. Rant over.)

    Ian

    0
  • Alan Sh

    Jerry, it does depend on how the DB is organised. If a record is unique to a photo, you could just lock the components relating to that - and someone else could edit a different photo.

    But as we have no idea (well, I don't) how it's organised, locking the whole DB is probably the easiest way to fix it.

    Alan

    0
  • Jerry C

    Yes, a DB could lock the record with all data related to a photo when the user accesses it. Later, when it is unlocked after that user closes the DB, another user could make additional edits if they have read/write permission. When I was in high school, while I was away on a band trip, my mother repainted my room. I liked it the way I left it. Feelings were hurt. 

    I am coming around to the realization that this is less a database problem than a problem related to sharing a photo database with others. I think in this case I may have missed the forest for the leaves. So, Alan, I think you are right and just locking a database in use is enough. 

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.