Can I share catalogues?
Running the latest version of C1 Pro.
I have a NAS server which holds folders I can access from both my PCs as drive letters (so X: points to a folder on the NAS server and the same files are accessible from both PCs).
Is there a way I can create a cataloge on the X: drive on one PC (windows 11) and use it on another PC (also windows 11)? I can see how to create it on one PC and that works, but I can't see how to use it from the other PC. All I seem to be able to do is import.
So, is this possible and have I missed something?
Cheers
Alan
-
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 -
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 -
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 -
That's fair enough. I don't normally leave C1 open if I'm not using it.
Alan
0 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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
Please sign in to leave a comment.
Comments
13 comments