PDMWorks 2005 problem - have you seen this?

We just upgraded to 2005, including our PDMWorks. Everything is going
splendidly, excpet for one thing. A user is trying to check an assembly into
the vault, and gets the following error message:
Unable to write custom properties to the file "5003338-011.SLDPRT. Please
make sure that the file is not being used by another program.
Well, it's certainly not being used by another program, so we used
SolidWorks Rx (wayyy cool by the way) to isolate the problem. Using the
option to "turn off" options/settings, the assembly easily checked in to the
vault. Next, we experimented with settings in SolidWorks, and tracked it to
the system option "Search file locatons for external references". If the
option is checked, PDMWorks check-in fails. If the option is not checked,
all is right with the world. This happens on everyone's machines.
Dell Precision 2.6Ghz
1GB RAM
Some have Win2K, others have WinXP (SP2)
(SP2 is NOT the problem - this happens in Win2K as well)
I know, I know...Doc, it hurts when I do this. Doc: Well, don't do that.
SolidWorks is aware of our issue, and they have agreed (insisted actually)
to look at our vault data. But, I would like to ask if anyone else has seen
this problem, or would you be willing to try to replicate it.
Thanks,
Richard Doyle
Reply to
Richard Doyle
Loading thread data ...
Richard,
There's someone named Ed Ortiz in the SolidWorks Discussion Forum that's having the exact same problem. Look in the PDM/Works section.
Dave H
Richard Doyle wrote:
Reply to
Dave H
Dave, I work with Ed, and I've been tasked with correcting the problem. SolidWorks is on top of it, but so far we seem to be the only folks in the land with the problem. I'm just fishing to see if anyone else had seen it.
Richard
Reply to
Richard Doyle
Richard,
Just out of curiosity, is your vault locked down. Is it visible to SW users? And is the vault on a logical drive that also contains non-vaulted SW files and that is listed in the Reference files settings?
Reply to
P
Richard:
What directory is your Tools, Options, File Locations, Referenced Documents pointing to? Network? Read only? Does removing a path from the list allow it to check in even with the "Search File Locations" turned on?
Does the 5003338-011.SLDPRT file have external references, or is there anything of note about it? (in context, mirrored, base part,etc.)
How is the Tools, Options, External References, Load Referenced Documents setting set?
Is that part from a library folder (designated on the Toolbox tab)?
Do you have any macro features in any parts?
What kind of machine/OS is the server running on?
I'm definitely interested in this issue. Please keep us updated.
matt
"Richard Doyle" wrote in news: snipped-for-privacy@uni-berlin.de:
Reply to
matt
Matt (and P), This issue started after we upgraded to 2005. Nothing unusual about the upgrade, followed all of the instructions, didn't change any permissions, the vault is visible and accessible to all. Strangly enough, we can check-in individual parts (from the same assembly) without a glitch.
See my other answers below.
Richard
The only referenced document path is pointing to the common toolbox folder on the server. And yes, removing this file location "solves" the problem. It should be noted that the assembly I am checking in does not have any toolbox parts in it.
Nope, nothing external is referenced. And this isn't the only culprit part, it's specific to the first part in the assembly. In other words, attempting to check in a different assembly causes the same error - with the first part in the tree (I hope you can understand that statement, cause it ain't very clear to me).
Set to "all"
Nope
Nope
It's a WIN2K server, probably put together by our crack IT staff in 1941. It's hard to make out the machine brand with all of the duct tape and bailing wire, but we've never had a problem before the upgrade.
SolidWorks is interested too. Joy is sending me a USB DVD drive today so we can dump the vault and send it back. I don't think it's a vault issue - judging by the fact that when I turn off the external reference switch it works. Also, removing the reference to the toolbox directory fixes the problem. Thing is, these setting didn't change between 2004 and 2005. We don't need to search external references because our file structure is flat. Setting the toolbox path is all we should need. Too bad that doesn't work any more.
Any suggestions you can offer are appreciated, although the workaround we found is fine so far.
Thanks,
Richard
Reply to
Richard Doyle

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.