Read Only Error Message & Crashes

We've been having a couple seemingly related frequent, but intermittent
problems for a long time. The first one is when we bring a read only
part (stored on our network) into an assembly hit save and it crashes.
The second one is happens when you have an assembly open with read only
parts or sub assemblies in it and you go to measure or mate one of
these read only parts (sometimes all you need to do is put your cursor
on top of it, or when you're inserting a new read-only part) and we get
these repeated warnings saying
"Document \Partnumber.sldprt is opened for read-only
access and is not available for write access. You must obtain write
access to this document to complete the operation"
I understand the document is read-only, but the operation is not
something you should be prevented from doing. Most of the time, this
message comes up repeatedly (for the same part). You end up having to
play whack-a-mole with the ok button...if you can click it fast enough
you can get out of the loop and exit the command or whatever is making
the message come up.
This has happened in several different assemblies and with lots of
different read-only files. It's independent of SP and version of
SolidWorks. I've repeated the problem in several sp's of 2005, 2004
and 2006. At least 4 people have reported these problems, 2 of which
have it happening on a regular basis. We're running XP.
It seems to be log-in specific. We've had one user try another
person's machine (that wasn't having the problem) and it happened
there. We've re-loaded SW, Reloaded their window's profile, switched
machine completely, they moved their cube (different network
connection) and still the problem occurs. It does stop happening if
the individual logs in as and administrator and has full write access
to all files. But, we can't have that. We don't have a PDM system so
we control permissions by storing files in different folders (a working
directory and a controlled directory).
Our VAR believes this to be a network/rights and privileges problem.
Our IT department isn't sure what to do. If this is truly a Network
or XP problem, than I'm having problems finding someone with enough
knowledge of both XP and SolidWorks to figure this out. I appreciate
any help or ideas. TIA
Reply to
Loading thread data ...
I've had a similar problem, although I did not crash, but did play the whack-a-mole game. I had a read only directory which I was using parts out of. That was the problem, SW wants to write a ~.tmp file for every opened assy or part, and wants to place it in the same directory as the part is opened from. The error message was misleading, the fix was pretty simple. Change the directory to read/write for everyone, then "select all" the files within the directory and make only the files present "read only". SW can then write its temp files and is happy. Hope the fix is as simple for you.
Reply to
Two other things to consider: Under System Options - External References, make sure you check the box next to: "Don't prompt to save read-only referenced documents (discard changes)." Lastly, it is never good to work over a network. FWIW Eddie
Reply to
Thanks Brian I'll give that a try to see if that fixes it. However, if that's really the problem than we're going to need PDM ASAP.
Eddie, Yes we do have that box checked and I know network = bad :) Not much I can do w/ 20 users and no PDM. Thanks for your advice though.
Reply to
Well we finally solved the wack-a-mole problem. It was a system option....external ref/ automatically generate names for referenced geometry was checked on (it's off by default). SolidWorks was trying to rename the faces of the read-only parts when it created a mate and error out. Apparently this setting makes your system very sensitive to read-only parts because it happened when measuring them as well.
Strange, but I'm glad that ones over....Thanks VAR!
Reply to

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.