---

Meldung.jpg

Hallo zusammen,

wir sind im August von "SolidWorks 2015, Windows 7" auf "SolidWorks 2017, Windows 10" und haben seit dem bei manchen Baugruppen beim Laden eine Meldung ob ersetzte Dateien vom Originalort geladen werden sollen. Im Anhang befindet sich ein Screenshot.
Diese Meldung kommt, egal ob wir die Datei direkt über SolidWorks, oder über die MaxxDB laden.

Die Dateipfade wurden nicht geändert und egal ob ich den originalen oder den aktuellen Speicherort auswähle wird der gleiche Pfad angegeben.

Kennt jemand die Meldung und kann mir erklären woher die kommt.

Vielen Dank im Voraus

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thorsten.

Wie ich sehe habt ihr MaxDB als Datenbank. Kann es sein, das die Meldung von dieser veranlasst wird?

Gruß
ThoMay

------------------
Hast du Fragen?
Brauchst du
Schaut mal nach im Bereich
Alle Foren => Wissenstransfer.
oder
Konstrukteure Online hier bei CAD.de
Richtig fragen -
Nettiquette - Konstruktionshilfen - Systeminfo - Unities - CAD Freeware - Forenübersicht - 3D Modelle - SolidWorks Videos

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thorsten,

ich kenne die Frage in ähnlicher Form (SWY 2014) da kommt so eine Frage wenn ein Teil/Baugruppe in verschiedenen Unterbaugruppen verbaut ist und aus unterschiedlichen Verzeichnissen geladen werden soll. HTH

BTW ich würde das Laden vom Originalpfad wählen und unten links den Haken setzen, dann wäre für die Zukunft Ruhe. Ich weiß dass das evtl. zu Wiederaufbaufehlern führen kann aber es sollte auch nicht sein dass ein Teil/Baugruppe redundant in Verschiedenen Ordnern zu Hause ist.

------------------
Grüße

Jörg

man hat nie Zeit es richtig zu machen, aber immer genug Zeit es nochmals zu machen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@ThoMay
Wie ich schon geschrieben habe, kommt die Meldung auch mit deaktivierter MaxxDB, deshalb denke ich nicht dass es davon kommt.

@Jörg
Ich habe schon unser ganzes System nach den Dateien durchsucht, und keine doppelten Dateinamen gefunden. Bei kopierten Dateien ist zumindest vorne oder hinten etwas angehängt.
Die Meldung unterdrücken finde ich auch keine Lösung, MSN sollte die Ursache finden und beheben.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
ja, dieses Meldefenster kommt bei uns auch erst, seit dem wir auf SW2017 gewechselt haben.
Ich habe dies ausführlich mit unserer Hotline besprochen, aber noch keine Lösung dafür gefunden.
Leider lässt sich so eine Konstellation nicht auf einem anderen Rechner reproduzieren.
(habe eine Testbaugruppe zum Provider geschickt)
Wegen der fehlenden Reproduzierbarkeit sendet unser Provider dieses Problem nicht zu SolidWorks nach Amerika.

Wir sind auch an einer Lösung Interessiert.
Evtl. finden sich ja hier noch ein paar Ansätze.
Das Meldefenster abzuschalten halte ich für keine gute Lösung.

Frage an Thorsten:
Ist das Laufwerk o:\ in deinem Pfad ein gemapptes Laufwerk?
Bei uns werden nämlich immer nur Dateien vermisst, welche sich in einem gemappten Laufwerk befinden.

Grüße, Andi  

------------------
Hast du kein Problem?
Such dir eins. ( Und löse es )

[Diese Nachricht wurde von Andi Beck am 06. Okt. 2017 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Andi,

ja das Laufwerk O:\ ist ein Netzlaufwerk, ist unser CAD-Laufwerk wo alle CAD-Daten liegen.

Werde mal versuchen mit dem Support über Teamviewer was hin zu bekommen. Muss aber erst mal schauen was meine Kollegen in meinem Urlaub schon mit dem Support getestet haben.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thorsten,
bei uns ist ein bestimmter Ordner auf dem Server als Laufwerk S:\ gemappt. (Netzlaufwerk verbunden)
Darin befinden sich unsere ganzen Kauf- und Normteile und auch sonstige SW-Dateien, welche sich nicht im Tresor Workgroup befinden.
Unsere ganzen Pfadangaben gehen über dieses Laufwerk S:\ und nicht über den tatsächlichen Netzwerkpfad.

Ich habe eine starke Vermutung, das es evtl. damit zu tun hat.
Diese Infrastruktur lässt sich ja nicht so leicht anderswo nachbilden.

Grüße, Andi

------------------
Hast du kein Problem?
Such dir eins. ( Und löse es )

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Andi,

wir haben ja kein PDM mit Tresoren, sondern die MaxxDB und die Arbeitet ja mit der Windows Verzeichnisstruktur und in dem Ordner MaxxDB liegen diese ganzen Dateien in verschiedenen Ordnern.

Werde am Montag mal versuchen ob ich durch etwas die Meldung nachvollziehen kann.
Habe den verdacht, dass ähnliche Dateinamen als gleiche gewertet werden, wenn nur ein kleines Präfix angehängt ist.

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Zusammen,

habe länger mit dem Support telefoniert, leider ist das ein Bug in SolidWorks.

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von thorsten_s:
Hallo Zusammen,

habe länger mit dem Support telefoniert, leider ist das ein Bug in SolidWorks.

Gruß
Thorsten

---

...ich denke eher das ist ein Bug im MaxxDB. Wenn's ein SolidWorks-Problem wäre hatten das Problem hier sicherlich mehr Benutzer.

------------------
Grüße

Jörg

man hat nie Zeit es richtig zu machen, aber immer genug Zeit es nochmals zu machen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

haben leider das gleiche Problem ohne PDM-Tresor oder MaxxDB. Ist auch erst aufgetreten, nach dem Update auf 2017 SP3

Danke für die Geduld in der Hotline 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

es ist definitiv ein Problem von Solidworks, und nicht von der MaxxDB.
Habe es mit dem Support von der MaxxDB eroiert und auch ohne die MaxxDB tritt der Fehler auf.

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,

ich kann dies auch bestätigen, wir verwenden die Zeichnungsverwaltung von ProAlpha (CA-Link) mit SWX 2017 und wir bekommen die gleichen Meldungen, ob mit oder ohne Zeichnungsverwaltung. Wir haben es hier pragmatisch gelöst mit " Datei vom Originalort laden" + Haken.
Glücklich bin ich damit nicht, aber aktuell scheint es zu funktionieren. Weiterhin sind mir noch so einige Sachen mit SWX 2017 aufgefallen, die es vorher so nicht gab, und ich meine jetzt nicht im positiven Sinne von technischem Fortschritt -> eher Rückschritt, aber diese Tendenz hat SWX meines Erachtens in den letzten Versionen (so ab 2014) schon gezeigt. War immer sehr zufrieden mit dem Produkt, bin nur etwas entäuscht über die aktuelle Vorgehensweise und der immer neuen Zusatzanwendungen, anstatt sich dem Kernprodukt wieder mehr zu widmen.
So das musste ich jetzt auch noch loswerden....

Gruß Robert

------------------
"Da Probleme aufgetreten sind verkaufen wir diese
jetzt nicht mehr als Fehler sondern als Features"

http://www.brunner.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thorsten,
gibt es zu diesem Bug ein SPR, an das man sich dranhängen kann?

Grüße, Andi

------------------
Hast du kein Problem?
Such dir eins. ( Und löse es )

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Andi,

leider weis ich keine SPR.

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,
ich kenne das Problem ebenfalls auch ohne MaxxDB.

Eigentliche kenne ich die Regel, dass SolidWorks beim Auflösen von Baugruppenreferenzen immer erst in den geladenen Dateien, dann im Verzeichnis der Baugruppe, dann im zuletzt geladenen Pfad der Referenz und am Schluss in den Suchpfaden sucht.
Nach dieser Regel darf der genannte Fall nicht vorkommen, da er die Referenz ja im Baugurppenverzeichnis gefunden hat. Nun will er offensichtlich eine Entscheidung, die früher vom Programm beantwortet wurde.

Nach meiner Kenntnis passiert das auch nicht in allen Baugruppen, sondern nur in solchen, die eine Ersetzung per API erfahren haben (SwDocumentMgr::ISwDMDocument::ReplaceReference oder :SldWorks::ReplaceReferencedDocument, da bin ich noch nicht sicher).
Man kann im Vergleich mit vorherigen SolidWorks-Versionen auch abweichende Verhalten feststellen. Während SolidWorks 2015 noch genau nach der obigen Regel öffnet, macht SolidWorks 2016 genau das Gegenteil und öffnet vom Originalpfad, SolidWorks 2017 stellt nun diese Frage. Beim Öffnen über API kann man diese allerdings nicht mit einer Option beantworten, weshalb derzeit eine Anfrage bei SolidWorks API-Support läuft.
Wenn es daher Neues gibt, kann ich gerne mehr dazu schreiben.

Viele Grüße
Armin

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Datei-suchen-c-Arbeitsverzeichnis-2.png Dateipositionen-2.PNG SolidWorks-ersetzeDatei.zip

Hallo,
vermutlich haben unsere Hotline und ich die Ursache und die Lösung gefunden.

Ich habe noch im alten Jahr ein RX-File an unseren Provider geschickt, der wiederum dieses zu SW nach Amerika gesendet hat.
Unsere Hotline konnte unseren Fehler nachbilden, die Amerikaner nicht, weshalb es zu einem mehrmaligen hin und her kam.
Meine ursprüngliche Vermutung, dass das Problem was mit gemappten Laufwerken zu tun hat, hat sich nicht bestätigt, da ich auch eine Problembaugruppe mit einem lokalen Laufwerk gefunden habe.

Das eigentliche Problem hat was mit Groß- und Kleinschreibung des referenzierten Pfades zu tun.
In unserem Fall sieht das so aus:

S:\Vorlagen versus s:\vorlagen
C:\1Arbeitsverzeichnis versus c:\1Arbeitsverzeichnis

Wie diese unterschiedliche Schreibweise zustande kommt, ist noch ungeklärt.
Auffallend ist, wenn sie gemischt vorkommt, kommt dieses Meldefenster.

Nun gibt es ein unterschiedliches Verhalten von SW, je nachdem, wie man dieses Meldefenster bedient.
Mit Bestätigung von "Datei von Originalspeicherort öffnen" ändert sich nichts.
Man kann die Baugruppe speichern, das Problem bleibt bestehen.
Lässt man allerdings dieses Meldefenster durchlaufen, ohne eine Option ausgewählt zu haben, ist das Problem nach speichern der Baugruppe weg.
In der beiliegenden Excel-Tabelle habe ich das unterschiedliche Verhalten mit der Groß- und Kleinschreibung dargestellt.

Es gibt aber auch noch eine generelle Lösung für dieses Problem, bei der dieses Meldefenster erst gar nicht mehr aufpoppt.
Wir haben unter Systemoptionen - Dateipositionen - Referenzierte Dokumente unsere Pfade eingetragen. (siehe Bild)
Seit dem kommt dieses Meldefenster nicht mehr.

Unser Provider hat diesen Fall jetzt zu einem internen zwischen Provider und SW gemacht, weshalb es dazu kein SPR gibt.
Diese Vorgehensweise soll eine andere Tragweite haben als sonst üblich.
Wollen wir hoffen, dass SW sich diesem Problem annimmt.

Jetzt würde mich noch Interessieren, ob ihr diese Analyse bestätigen könnt.
Eine schöne Arbeitswoche wünsche ich euch, ich fange morgen wieder an.

Grüße, Andi 

------------------
Hast du kein Problem?
Such dir eins. ( Und löse es )

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Andi,

leider kann ich deine Analyse nicht bestätigen.
Bei uns sind in den Referenzen alle Pfade gleich geschrieben und trotzdem kommt bei einem Teil die Meldung.

Das speichern der Baugruppe nach dem öffnen ohne Eingriff bringt auch keine Besserung.

Ich habe auch versucht den Pfad bei den referenzierten Dokumenten einzutragen, dann kommt zwar die Meldung nivht mehr, aber die Baugruppe brauch ein vielfaches an Ladezeit.

Gruß
Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP