Dammit, Solidworks, let go of my files!!

Somebody told me that the file will be released after the assembly is rebuilt. This actually seems to work. I think I was told this in response to submitting the issue as a bug.

I've seen this problem even after the file has been rebuilt, saved, and SolidWorks shut down, It takes approximately 10 seconds or so to release all files.

Best Regards, Devon T. Sowell

That indicates to me that this behavior is tied to the saving of the files. When you exit SW, watch what happens in your task manager. The icon disappears from your Applications immediately, but SW still exists as a process. On some of my assemblies it takes much more than 10 seconds for the process to disappear. I believe that SW shuts down the visible parts of SW while it is continuing to file your parts so that it looks like it's much faster than it really is.

Jerry Steiger Tripod Data Systems

It's called poor memory management. We see out of resource errors everyday and have had memory management issues and unhandled errors since we were demoing the software. I'm crossing my fingers that 2004 has addressed the resource management issues. Not even setting the VM smaller, using the 3GB boot switch or tweaking this and that has really helped. The bad thing is that you can't really recreate it using exact steps so there goes the chance of assigning an SPR. Fortunately it appears that they accidentally fixed the config switching problem. Try working with 5,000+ part assemblies and RapidDraft drawings and you can join me in the leagues of professional white screen/hourglass starer.

It's called poor memory management. We see out of resource errors everyday and have had memory management issues and unhandled errors since we were demoing the software. I'm crossing my fingers that 2004 has addressed the resource management issues. Not even setting the VM smaller, using the 3GB boot switch or tweaking this and that has really helped. The bad thing is that you can't really recreate it using exact steps so there goes the chance of assigning an SPR. Fortunately it appears that they accidentally fixed the config switching problem. Try working with 5,000+ part assemblies and RapidDraft drawings and you can join me in the leagues of professional white screen/hourglass starer.

"Devon T. Sowell" wrote in news:rIYVa.10669$ snipped-for-privacy@news3.news.adelphia.net:

I'd call that a Windows problem, just to be fussy. Why is windows explorer so slow?

Dale Dunn wrote in news:Xns93C97B35C1C8daledunnatjamestoolc@65.24.7.150:

That's what I'm starting to think. I've had trouble deleting empty folders in Windows XP because some process had a hold on them for god know what reason. Only a reboot would release them.

Windows Explorer gets more and more complicated with every OS release. With all the hooks and handler interfaces that the shell exposes, there's no telling how many DLLs are loaded everytime you browse a folder or right- click on a file (well, actually, you could find out by examining the appropriate registry entries). And there's no way to know how well they're written, either.

If you crashed, and the ~tilde file is still there, it may cause Windows to keep the file locked.

Mike Wilson

Scott,

I'm on Win 2000 SP3 and wits end.

That's good IMO (that's what I use) How much memory are you using? 1gig or more? If your opening 5000+ assemblies you should be using more than a gig of memory IMO. Close all programs in the background if you haven't already when opening your files.

What video card are using? that to can have a bearing on opening your files and causing unhandled errors as well.

Regards, Scott

If these are files on a network you can find the ones being held open on the server. On the server, go to My computer, right-click, choose Manage, go to Shared Folders, and Open Files. You will often find the offending file being held open even if you have closed out of SolidWorks. Haven't figured out why yet. Be careful if you are in a multi-user environment because someone may have an assembly open that causes the lock on your file (even with a PDM).

We have 2 1GB sticks of RAM so it should be running in DDR/PAT mode. All programs are closed and we no longer even have antivirus disabled in the background. The video cards we use are Quadro4 980 XGL's running 43.51 version drivers with OpenGL set to 'SolidWorks'. We haven't tried using VGA mode since it really doesn't seem to be a video related problem. For instance, we get crashes when simply saving a drawing with the model loaded and those saves take 15 minutes at times with the CPU laying around at about 15%. I believe I read a thread in which Ed Eaton and a few others experienced this issue so I know I'm not just being nit picky on this one. I think I have narrowed down the problem to a memory management/allocation issue. If we open the assembly and then the RapidDraft drawing it seems to be more stable and uses much less RAM then if we open the RapidDraft drawing and then load the model. I know RapidDraft drawings have embedded assembly data. Sometimes it seems like there are two assemblies open in memory: the assembly file data and the drawing embedded assembly data and sometimes I think that there may be trouble with that. I could be way off the mark with this idea since it is pure speculation, but I really don't know what else it could be. If there's anyone out there that also manages large assemblies I would like to hear what comments you have about your experiences with 2001+ and 2003.

"Scott" wrote in message news:...