Failed to save? Cannot obtain memory?

Are you getting a lot of error message such as "Failed to save document" and "SolidWorks could not obtain required memory?" These are symptoms of low network response and/or low workstation memory.

To see if you're running out of memory, use the Windows Task Manager and click on Performance tab. The Commit Charge Peak is the high-water mark of memory usage since the last reboot of the system. If that exceeds physical RAM, you're into swap, which isn’t good. If it gets close to the Commit Charge Limit, then you're running out of swap also, which is very bad. Below you can see an example of a Dell M90 just running Microsoft Outlook 2007. It has 2GB physical RAM and a 4GB swap file.

Don't forget your overall hard disk space too. It is recommended that you have at least 10% of your hard drive free at all times. If you run low on disk space and SolidWorks cannot create a journal file, that is a cause of the "SolidWorks could not obtain required memory" error message when you attempt to open a file.

If your workstation memory (RAM and hard disk) is fine, then you have to look at your network. Graphics Systems Corporation recommends employing a dedicated server for hosting SolidWorks files. In addition, we recommend the use of a PDM system configured to allow design collaboration across the network while still having users work locally with their SolidWorks files. The network itself should have as much bandwidth as possible between the workstation and engineering server. Ideally, the workstations is connected at 1GB to a switch that has a 10GB connection to the server, but a 100MB workstation / 1GB server scenario would be what we consider a bare minimum requirement.

There are three SolidWorks settings that might impact “failed to save document” occurrences over a taxed network:

• The location of the SolidWorks journal file. This should be on a local machine rather than on the network.
• Under Tools->Options->System Options->Backups, set Save Auto recover info every “n” changes to a higher value. In addition, reduce the number of backups per document to 1.
• If the location of the backup files is the same as the original file, (Tools->Options->System Options->Backups->Save backup files in the same location as the original is checked), then change it to another location on a local drive.

Comments

[Mikka Roessler]

It also depends what kind of "fail to save" you have. A "fail to save" during editing of an existing file that has already successfully saved previously is different from a "fail to save" the first time you go to save a document.

In our experience the "FTS" for a new document is caused by network inconsistencies. For us it was two issues. The time setting on the servers did not match the time on the client workstations. Because of this the entries in the DNS were incorrect and resource names were not being resolved to IP addresses fast enough for the save function and it failed mid-save.

In our case the "FTS" on a new file was the result of the file handles being left open on the server and the beginning of the file already being created with a zero-byte size after the save process had timed out and crashed. If you tried to save again the file already existed but could not be deleted by the user until the file handles were closed on the server or timed out in 8 to 24 hours.

This was proven out by remapping all network drives for engineering to IP addresses and the problem went away immediately. When we fixed the "Net Time" and got DNS back up to speed the issue disappeared for resolved named resources.

[Jeff Setzer]

Thanks for the comments and additional examples, Mikka. Doos anyone else have examples of things they had on their network that caused FTS?