Has anybody here solved the problem of the liquid class database being on the local PC when deploying methods at scale via network drives?
I know one way to tackle this is to have a synched Hamiltons folder that is pushed from a master repo to the system endpoint, however I am interested in if anybody has found a different way to reference the same .mdb for the liquid classes, say if that .mdb lives on a network drive.
TL;DR, how can we reference a different liquid class database? Where is that reference set up in the configuration?
Along these lines, I’d love to get into a deeper thread for discussing tips and tricks, stories of success and failure, when deploying methods at scale.
I think there’s a library in the LVK method that “rolls back” edited Liquid Class settings.
Maybe one application of this, would be in the method you define the liquid class settings you want. Grab a Liquid Class specific to your method to modify and then use. Hope that makes sense.
In C:\Program Files (x86)\HAMILTON\Config\ML_STARType.cfg there are a couple keys that look like they would specify the location of the database, but I’ve never tried pointing them to a file in another directory
StandardLiquidDbName, “‪ML_STARLiquids.mdb”,
StandardLiquidDbPath, “”,
Another potential option is to have your methods call the liquid class editor from the command line to import the liquid classes from the network file
HxCoreLiquidEditor.exe /instrumentclass ML_STAR /import “”
If I’m understanding the question correctly and you want identical liquid class databases on each instrument PC with no ability to edit them locally, you should be able to replace the liquid class .mdb file whole cloth instead of referencing a different db. I would likely either create a symlink from the local PC to the .mdb on the network drive (so that the robot can pretend it’s a local file) or initialize a git repo in the HAMILTON/Config folder that gitignores everything except the liquid class db.
There may be edge cases that this approach misses and I’m sure it’s not the officially sanctioned way to do things, but it’s worked for me when I’ve tested it in the past (though haven’t deployed at scale).
