Het is nogal zeldzaam bij de opnames... Zijn al uw onderdelen up-to-date met uw versie van solidworks (vooral bibliotheekelementen -meestal alleen-lezen-) Krijg je hetzelfde bericht als je onder een andere bestandsnaam opslaat?
Ik hoop voor je dat dit gewoon een manier van praten is en dat je regelmatiger opneemt (elke 10/15 min)
Anders is er één weg om te verkennen: wanneer is het originele bestand ontstaan? Bij Créo had ik regelmatig het probleem dat de creatieve versie te oud was in vergelijking met mijn werkende versie. Jaar-op-jaar compatibiliteit is niet noodzakelijkerwijs stabiel in de tijd. Als het bijvoorbeeld is gemaakt met Solidworks 2004 en u Solidworks 2023 gebruikt.
Het is een pijn in de kont... Maar dat zijn de grenzen van versiecompatibiliteit. Meer dan een oplossing => het bestand opnieuw maken
Hallo jerome.lamar, Inderdaad, het overkomt mij ook wel eens. Dus mijn oplossing is om het onder een andere naam op te slaan, of om het helemaal opnieuw te doen, op zoek naar een model dat erop lijkt... Ziezo, veel succes, @+. AR.
Is het een bestand waarvan op enig moment een back-up is of wordt gemaakt op het netwerk?
Als het alleen lokaal is en u de enige bent die aan dit bestand werkt, raad ik een analyse van de integriteit van de schijf aan. Bijvoorbeeld, van " klik met de rechtermuisknop op de speler > eigenschappen > tools > het aanvinken " door aan te vinken " probeer automatisch fouten te herstellen ".
@Maclane , Ja, de betreffende documenten zijn up-to-date, het zijn geen bibliotheekstukken. Registratie onder een andere naam is mogelijk. Het is alleen de opname van een reeds bestaand stuk dat het verknoeit.
@coin37coin , Ja, idealiter nemen we allemaal elke 10/15 minuten op, maar de wet van Murphy is er: als een bestand moet verknoeien, is het noodzakelijkerwijs het bestand waar we 2 uur aan hebben gewerkt zonder te hebben opgenomen... Het betreffende bestand was een paar weken eerder gemaakt, dus geen probleem met de of andere versie.
@A_R Dat is wat ik uiteindelijk heb gedaan. Verwijder het onderdeel en maak het opnieuw.
@Sylk Het is een bestand dat op een server is gearchiveerd, verkregen en vervolgens is uitgepakt. A priori is het de lokale opname die een probleem vormt. De schijfcontrole is een interessant nummer, ik zal zien.
Haaaa, het is DAT beroemde bestand waar je dingen probeert zonder meteen te willen opslaan. Ik sympathiseer ^^
Betekent dit dat u het van de server haalt, het op uw terrein plaatst en het vervolgens opnieuw op uw server integreert? Wordt het corrupt wanneer u het weer op het netwerk zet of al wanneer het zich op uw terrein bevindt?
Ik had deze zorg ook bij complexe onderdelen; om het op te lossen, ging ik naar Optie en vervolgens naar back-up / herstel en ik activeerde de automatische back-up elke 10 minuten en schakelde het opslaan van een back-up in de originele map in.
Het is prachtig. De auto save is de optie die ik heb verwijderd om te voorkomen dat Solidworks vastloopt en crasht. Persoonlijk had ik aanzienlijk meer crashes met betrekking tot de automatische back-up (meerdere per week of maand) dan beschadigde bestanden (een paar bestanden gedurende een jaar werken met 6 mensen).
Om het risico op corruptie te beperken, vermijdt u bestanden uit 2005 die zijn opgeslagen in 2008, vervolgens 2012, vervolgens 2020 en een goed dozijn keer zijn gekopieerd/hernoemd...
Hetzelfde standpunt over het automatisch opslaan (het start wanneer het niet zou moeten en bevriest het hele ding). En wat betreft de oude bestanden, ja, u zou idealiter de sjabloonbestanden bij elke nieuwe versie opnieuw moeten doen.
Het bestand is niet "echt" beschadigd. SW geeft me deze foutmelding, maar als ik SW sluit zonder het bestand op te slaan en opnieuw open, kan ik het zonder problemen bewerken en opnieuw opslaan. Het is gewoon dat ik het werk dat ik heb gedaan verlies.
Hallo, er kunnen verschillende tests moeten worden gedaan. 1-> Raakt het bestand beschadigd wanneer het op de server wordt opgeslagen, maar onder een andere naam? 2-> Is het door het bestand op de server op te slaan, maar de server eerder als een netwerklocatie te hebben beschouwd (bijvoorbeeld Z:/). Dit kan te wijten zijn aan een te lang adres of moeite om contact te houden met de server 3-> Door de bestandsnaam te vereenvoudigen, blijft het probleem hetzelfde? Adressen die te lang zijn of met bepaalde tekens kunnen inderdaad een probleem zijn.
Hallo, ik heb dit probleem al gehad, het kwam van een oud defect bekabeld netwerk, de oplossing was om onder een andere naam te registreren om het werk niet te verliezen... Succes!
Inderdaad, als dit gebeurt, voel je je een beetje alleen!! Dit is mij al lang niet meer overkomen. De enige oplossing was om een save te maken - onder.
Maar een paar jaar geleden en met het risico dat iemand mij in mijn entourage leest, is het mogelijk om deze bug opzettelijk te reproduceren met een .txt bestand dat is hernoemd naar .sldprt . Ik hoop voor je dat er geen kleine slimme persoon is die zich verveelt!!
Deze crashes werden voor mij verklaard door " micro netwerkstoringen tussen onze lokale SW-software en onze server ". We hebben elk een lokale installatie (individueel station). We werkten live op de server, maar na deze crashes hebben we onze methode al lang geleden veranderd. Op een kleine studie werken we op de server in de juiste map. Bij een zware studie (alles is relatief) werken we individueel aan onze c: en als de studie klaar is, zetten we over naar de server. De enige oplossing is om heel regelmatig na te denken over een " control+s " of de automatische back-up te programmeren met een " passende " vertraging ertussen. Als het bericht verschijnt, sla ik op door de naam op te slaan met een achtervoegsel " sos " om het te onderscheiden van het huidige bestand. Soms werkt het. Soms niet! Succes.