Hello
Regularly, I get this error message when I try to save a file I'm working on.
Forced to close the file without saving, which makes me lose several hours of work. It's quite painful.
Does anyone know where this crash comes from? And how can it be remedied?
Thank you
Hello
a bit like usual which version of SW? PDM? it rather crashes on the MEPs?
Hello;
It's rather rare at the recording...
Are all your parts up to date with your version of solidworks (especially library elements -most often read-only-)
Do you get the same message if you save under a different File Name?
What shocks me about this is this:
I hope for you that this is just a way of talking and that you record more regularly (every 10/15 min)
Otherwise, one avenue to explore: when did the original file originate? With Créo, I regularly had the problem when the creative version was too old compared to my working version. Year-over-year compatibilities are not necessarily stable over time.
For example, if it was created with Solidworks 2004 and you are using Solidworks 2023.
It's a pain in the ass... But that's the limits of version compatibility. More than a solution => recreate the file
Hello jerome.lamar,
Indeed, it also happens to me sometimes. So my solution is to save it under another name, or to redo it altogether, looking for a model that looks like it... There you go, good luck, @+.
AR.
Hello
Is it a file that has been or is being backed up to the network at any time?
If it's only local, and you're the only one working on this file, I recommend an analysis of the integrity of the disk. For example, from " right-click on the player > properties > tools > checking " by checking " try to automatically repair errors ".
Hello
Thank you for all your answers/leads.
@Le_Bidule , SW Premium 2023 SP3.0 , PDM 31.3
@Maclane , Yes, the documents concerned are up to date, they are not library pieces. Registration under another name is possible. It's only the recording of a pre-existing piece that screws up.
@coin37coin , Yes, ideally, we all record every 10/15min, but Murphy's Law is there: if a file has to screw up, it's necessarily the one we've been working on for 2 hours without having recorded...
The file in question had been created a few weeks earlier, so no problem with the version or other.
@A.R That's what I ended up doing. Delete the part and recreate it.
@Sylk It is a file that had been archived on a server, obtained and then extracted. A priori, it is the local recording that poses a problem. The disk check is an interesting track, I'll see.
Hello
What if you make a copy of a " corrupted " part and you try to work and save on it?
Haaaa, it's THAT famous file where you try things without wanting to save right away. I sympathize ^^
Does that mean you take it out of the server, put it on your premises and then reintegrate it on your server?
Does it become corrupt when you put it back on the network or already when it is on your premises?
Hello
I also had this concern on complex parts; to fix it, I went to Option then backup/recovery and I activated the automatic backup every 10min and enabled the saving of backup copy in the original folder.
It's beautiful.
The auto save is the option I removed to prevent Solidworks freezes and crashes.
Personally, I had significantly more crashes related to the auto backup (several per week or month) than corrupted files (a few files over a year of work with 6 people).
To limit the risk of corruption, avoid 2005 files saved in 2008, then 2012, then 2020 and copied/renamed a good dozen times...
Same point of view on the auto save (it starts when it shouldn't and freezes the whole thing).
And concerning the old files, yes, you should ideally redo the template files with each new version.
The file is not "really" corrupted. SW gives me this error message, but if I close SW without saving and reopen the file, I could edit and save it again without any problems.
It's just that I'm losing the job I've done.
Hello, there may be several tests to be done.
1-> Does the file get corrupted when it is saved on the server but under a different name?
2-> Is it by saving the file on the server but having previously considered the server as a network location (Z:/ for example). This could be due to an address that is too long or difficulty keeping in touch with the server
3-> By simplifying the file name, does the problem remain the same? Indeed, addresses that are too long or with certain characters can be a problem.
Hello, I've already had this problem, it came from an old faulty wired network, the solution was to register under another name so as not to lose the work... Good luck!
Indeed, when this happens, you feel a little alone!! This hasn't happened to me for a long time.
The only solution was to make a save - under.
But a few years ago and at the risk of someone reading me in my entourage, it is possible to reproduce this bug, deliberately, with a .txt file that is renamed to .sldprt . I hope for your sake that there is no little clever person who is bored!!
It seems very funny to make a colleague angry^^
Personally I think we have enough work and bugs on SW.
As a matter of correctness, I respect the work of others 
Considering the price of the equipment, I wouldn't take the risk of seeing him throw the computer out the window! 
These crashes were explained to me by " micro network outages between our local SW software and our server ". We each have a local installation (individual station). We were working live on the server but following these crashes we changed our method a long time ago.
On a small study, we work on the server in the appropriate folder. On a heavy study (everything is relative), we work individually on our c: and when the study is finished we transfer to the server.
The only solution is to think very regularly about a " control+s " or program the automatic backup with an " appropriate " delay between them. If the message appears, I save by saving the name with a suffix " sos " to differentiate it from the current file. Sometimes it works. Sometimes not! Good luck.