Vault view on a different drive.

[mp3-250]

We usually equip all our workstations with a SSD for their C: drive.
Unfortunately one was misconfigured and it got a HDD on the C drive and an empty SSD...it cannot be changed from our dept and oir IT refuses to reinstall the whole thing and it is not negotiable at the moment.

Our vault view is usually in a folder under the C: drive, so I am wondering if mapping the same folder but under the D: drive would cause some "bad surprise" from our loved PDM system.
Having seen al the strangest bugs, I am trying to confirm here if there is some issue or someone with a direct experience on the matter.

Mapping the SSD drive as a folder is not possible unless there is some trick like writing something inside the desktop.ini in the vault view folder.

[JSculley]

PDM doesn't care about the drive letter.

[mp3-250]

In theory I think so, but SW settings use an absolute path that points inside our vault from C: drive so I would need to modify them all to accomodate one install...

the ideal scenario would be to have the vault view under c: pointing at the d: drive (ssd) but it is probably not feasible.

Then I am scared about strange bugs I am not yet aware of.
I think an assembly component path is written in both the DB and the cad file and when caching those data locally everything is converted with "real filenames" from the DB and probably a path relative to the vault root written inside each file, so it SHOULD not matter. Nevertheless I got burnt with pdm so many times...

[JSculley]

In theory I think so, but SW settings use an absolute path that points inside our vault from C: drive so I would need to modify them all to accomodate one install...

That's a SOLIDWORKS problem, not a PDM problem.

the ideal scenario would be to have the vault view under c: pointing at the d: drive (ssd) but it is probably not feasible.

The ideal scenario would be for your IT department to do their job and fix the problem. I mean, what kind of IT department misconfigures a workstation and then says 'Oh well, deal with it'. Their JOB is to provide you with the tools you need to do your job. When they fail to understand that, the best approach is to make their lives as difficult as possible.

For example, since you will have to change all the file location paths in SOLIDWORKS to account for the difference on one machine and making those changes typically requires admin rights on the machine since it changes the registry and you probably don't have admin rights on your machine, make the IT folks do the work. If they don't do it in a timely manner, email your boss and CC the IT boss. Make it clear that employee using the workstation CANNOT DO THEIR JOB. Repeat this process as needed until the IT folks realize that they are spending way more time dealing with this than if they had just set the machine up properly in the first place.

[Craig Schultz]

In theory I think so, but SW settings use an absolute path that points inside our vault from C: drive so I would need to modify them all to accomodate one install...

the ideal scenario would be to have the vault view under c: pointing at the d: drive (ssd) but it is probably not feasible.

IT screwed up. They should fix it ASAP. As Jim said, emphasize that it affects the users ability to work, period. The amount of time IT would take to reconfigure doesn't even come close to all of the headaches/time wasted if you have to configure that one user/s machine/settings.

I love it when IT takes on the role of gatekeeper/god as to what happens because they, for no other reason, can.

[mp3-250]

Well other than this specific case I have other (few) users that switched from 2D to 3D, but until those machines lease expires they have to use them. Even those machines have a SSD as secondary storage, so it would be useful to know if a least the vault could be accessed faster than their hdd and a bettet way to integrate them with oher vaults configurations.

I appreciate the replies and I get all the points you made: I have already tried that route, but there are many things I am not going to write in a public forum going on, so I have to deal with this issue somehow.

[jcapriotti]

The PDM "get latest" should cache them properly regardless of the vault location on "C" or "D" drives. SolidWorks' search algorithm may find them correctly since the top level drive letter is the only thing changed. If not, you can check the option to search "Reference Documents specified in "File Locations". Then add the drive letter to the Document references under File Locations.

[Diaval]

PDM is setup to handle vault views that are in different paths or drives on different client machines. When PDM does a Get operation it will automatically update the reference file paths in the cached files to the correct path for the location of the vault view on the client. Users should not see any issue with using a vault view that is on a different drive or in a different path on the client machine.

[mp3-250]

@Diaval that is the ideal bug free scenario. I had some cases of a local cache with an assy which latest version was not updated with some components moved to a new path. it was on my test environment so I am te only one touching those files and the strangest thing is that the vault view was created AFTER the components were moved. (new machine with sw installed from zero)

in theory pdm should work well, but there are a lot of bugs and pits to fall in and I am interested to know if someone actually tried it.
the best wouldbe mapping the drive to a folder, but pdm does not get fooled by windows symbolic links and it wants a real folder for the vault root.