| | | Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für SolidEdge |
Autor
|
Thema: Bug aus SE14 SP9&10 mit SP12 eliminiert (909 mal gelesen)
|
Junix Mitglied Dipl. Ing.
Beiträge: 134 Registriert: 06.09.2002 SE ST9 Windows 7 - 64 Bit.
|
erstellt am: 17. Mrz. 2004 17:57 <-- editieren / zitieren --> Unities abgeben:
Hallo, "angeblich" ist der Bug aus SP9&10, welcher Parts endlos aufbläht und damit Solid Edge zum Stehen bringt mit einer Installation von SP12 und einem Abspeichern des Parts aus diesem Part eliminiert, ohne daß man das im Tagesrythmus von EDS/UGS aktualisierte "Zappertoool" über seine Daten laufen lassen muss. Wir machten bei uns folgende Beobachtung und ich wundere mich, ob es anderen genauso geht: Die Datei ist nur dann von "infections" befreit wenn die zwei Dateien "StatusChange.exe" und "StsChange.exe" - welche in dem "OpenSAve" Makro (bei uns v6.0.44) beigegeben sind - in dem Solid Edge Programmverzeichnis einkopiert wurden. Dieser Vorgang passiert jedoch nicht automatisch bei Einspielung vom SP12!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! D.h. obwohl man SP12 einpielt, werden oben erwähnte Dateien nicht in das Programmverzeichnis einkopiert. D.h.: Wenn die beiden Dateien (von uns manuell) in das Programmverzeichnis einkopiert wurden, so wird bei einem Speichervorgang die Datei von "infections" befreit. Wenn jedoch die beiden Dateien nicht in das Programmverzeichnis einkopiert wurden, so bleiben die Dateien "infiziert" und bremsen die Systemperformance aus. Aktualisierungszeiten von infizierten Dateien" 12-15 Minuten, bereinigte Dateien 1-2 Minuten! Wie geht es anderen? Danke für die Info Junix Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
CadKD Ehrenmitglied Konstrukteur
Beiträge: 1751 Registriert: 14.08.2002 SE ST5 SWX 2011 SP4 ProE WF IV, M080 ProE WF III, M200 ProE WF II, M171 Win7 64, HP Elite Book 8730W Core 2 DUO T9600 2,8 GHz 4GB DDR2 RAM nVidia FX2700M
|
erstellt am: 18. Mrz. 2004 09:06 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo Junix, das Problem ist nach Aussage eines SST-Mitarbeiters zwar mit V14SP12, bzw. mit V15SP2(soll demnächst kommen) gelöst. Allerdings nur soweit, dass neue Dateien nicht mehr infiziert und Bestehende beim Bearbeiten und Abspeichern wieder vom Datenschrott befreit werden. D.h., es muß auch der alte Bestand der möglicherweise schon infiziert wurde mit dem Zappertool überprüft werden um alle Dateien wieder in einen einwandfreien Zustand zu bekommen. Ich habe schon überlegt, ob es Sinn machen würde eine Interessen- gemeinschaft zu gründen die Schadenersatzansprüche gegenüber UGS geltend macht. Zwar sehen Software-Lizenzen meistens mit allerlei kleingedruckten Paragraphen solche Haftungsausschlüsse vor, jedoch ist hier von einem grob fahrlässigen Verhalten der SE-Entwickler aus- zugehen. Zumindest wäre es aber auch schon schön, wenn dadurch ein kleines Entgegenkommen seitens UGS in Form von z.B. gesenkten Wartungsgebühren oder ähnlichem bewirkt werden könnte. Die Wartungskosten pro Lizenz liegen über 130€ monatlich. Dafür erhalten wir schadhafte Software die immer mehr, auch an anderen Krankheiten leidet. Leider ist man bei UGS nicht bereit hier Wartungsverträge mit geringerem Leistungsumfang anzubieten. Ich könnte mir vorstellen, dass in größerem Unternehmen die Schäden, bzw. Ausfallzeiten durch diese Software-Geschichte wesentlich umfangreicher sind als bei uns kleinen Fischen. Hat denn da niemand die (Un-)Kosten für derartige Dinge verfolgt? Es kann doch nicht sein, dass ein Maschinenbauer bei Lieferung in die USA hier massiv die Gesetze der Produkthaftung beachten muss, andererseits aber amerikanische Software-Lieferanten nahezu jegliche Dinge produzieren können ohne dafür zur Verantwortung gezogen werden zu können? Wie denken andere Anwender über so etwas? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
modeng Ehrenmitglied V.I.P. h.c.
Beiträge: 7061 Registriert: 10.12.2003
|
erstellt am: 18. Mrz. 2004 10:47 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Moin, hmmm, also wir haben V14 Sp6 vor einem halben Jahr bekommen. Inzwischen ist dafuer SP12 draussen *und* V15 bereits mit SP2 -- mir scheint, das jetzt Patches fuer Patches fuer ... gemacht werden und das ganze droht wohl etwas instabil zu werden .... modeng Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
elsbett Mitglied
Beiträge: 450 Registriert: 26.03.2002
|
erstellt am: 18. Mrz. 2004 11:16 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo Junix Also, ich hab das mal durchgespielt, und komme zum Schluss, dass SE14 SP12 die Probleme behebt, OHNE manuelles kopieren der beiden von Dir genannten Dateien (dieses sind bei uns im Prog-Verz. NICHT vorhanden). Der Test lief so: 1. Prüfen, ob "StatusChange.exe" und "StsChange.exe" im Prog verzeichnis sind =>NEIN 2. Kopieren von zwei verseuchten Dateien in ein Backupverzeichnis 2. Öffnen und speichern/schliessen dieser zwei Dateien am Originalstandort mit SEV14SP12. 3. Kopieren der beiden "StatusChange" Dateien ins Prog. Verz. 4. Laufenlassen von Zapper mit der Dry-Run-Funktion, sowohl auf den zwei Dateien am Originalstandort als auch auf im Backupverzeichnis. Ergebnis: Zapper meldete bei den zwei Originaldateien (also gespeichert mit V14SP12) "Problem not found" Zapper meldete bei den Kopien im Backupverzeichnis: "Problem detected" Ergo hat ein öffnen, speichern und schliessen mit V14SP12 effektiv den Bad Stream entfernt. Gruss Eru... P.S. Eine Gemeinschaftsklage oder so sehe ich gar nicht konstruktiv, wir lassen uns doch nicht auf solches Niveau runter. Ich denke, dass SE aus diesem Schnitzer einiges lernen wird. Ich habe mich über den Fehler auch masslos geärgert, aber man muss auch sehen, dass SE sich in letzter Zeit funktionell enorm verbessert hat in ziemlich schnellen Schritten. ------------------ P4 1.8GHz, Win 2k, GeForce3 Ti 200, SE V14 SP 12 [Diese Nachricht wurde von elsbett am 18. Mrz. 2004 editiert.] [Diese Nachricht wurde von elsbett am 18. Mrz. 2004 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
modeng Ehrenmitglied V.I.P. h.c.
Beiträge: 7061 Registriert: 10.12.2003
|
erstellt am: 18. Mrz. 2004 13:06 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Moin, was hat das mit Niveau zu tun, wenn mir durch einen ziemlichen Bug in der Software eine Schaden entstanden ist und ich deshalb den Hersteller, der das mit einem 'Sorry Mr. Customer' abtut, notfalls juristisch, belangen will? Ich muss nicht alle Kroeten schlucken, die mir da angeboten werden. Ob ich nun per Gericht oder 'Gentleman agreement' versuch' etwas zu erreichen ist eine andere Sache -- letzeres ist wohl zuerst angesagt. Und letzlich ist das eine Entscheidung, die das Management treffen muss. Zur Frage der Produzentenhaftung, auch bei Software, hat es glaube ich in letzer Zeit einige geseztliche Aenderungen gegeben, die den Nutzer in eine bessere Position setzen. modeng Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
elsbett Mitglied
Beiträge: 450 Registriert: 26.03.2002
|
erstellt am: 18. Mrz. 2004 13:51 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo Modeng Nun, ich glaube eben, dass langfristig die ganze Haftpflichtangelegenheit den Produkten und der Innovation mehr schadet als nutzt, egal ob Software oder Hardware. Die Frage ist doch an sich ganz simpel: Ein Unternehmen investiert seine Kraft in die Entwicklung von neuen technischen Errungenschaften und Funktionen, und die Frage ist doch jetzt, wann bringt man das an den Markt. Wenn vor lauter Haftpflichtangelegenheiten ja kein Fehler im Produkt sein darf, verbratet man einen Grossteil der Entwicklungsenergie mit Tests und Absicherungen, statt sich bereits um wiederum neue Dinge zu kümmern. Die Wahl dieses Zeitpunkts ist eine Gratwanderung, sicher bin ich mir jedoch, dass verschärfte Haftpflichtsituationen die Innovation verlangsamen, und ganz bestimmt das Preis/Leistungsverhältnis. =>Ich finde bisher die Linie von SE recht seriös, der Kunde kann selber entscheiden, ob er die neuen Features von z.B. V15 gleich sofort braucht, und bei SP2 einsteigt, und dann halt ein paar Bugs finden wird, oder ob er lieber auf der mittlerweilen gereiften V14 noch ein Jahr fahren will. Zudem werden ja die SPs auch bei der Vorversion noch updated, auch wenn die neue Version längst draussen ist. Gruss Eru...
------------------ P4 1.8GHz, Win 2k, GeForce3 Ti 200, SE V14 SP 12 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Lars Ehrenmitglied V.I.P. h.c.
Beiträge: 4319 Registriert: 23.10.2000 Solid Edge
|
erstellt am: 18. Mrz. 2004 14:42 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo, hat denn jemand im Forum wirklich diesen Effekt gehabt? Also mir ist keiner bekannt. Wie sieht denn das ganze aus? Von welchem Faktor reden wir hier? Man muß aber sagen, das sich UGS PLM sehr bemüht Bugfixing zu betreiben. Immerhin gibt es Servicepacks die den Fehler beheben. Was das einzig ärgerliche an der Geschichte ist, das der Fehler erst mit einem Servicepack kam. Naja es kann ja nur besser werden. Vor einigen Jahren gab es auch mal einen Virenscanner, der in Solid Edge Programmdaten gelöscht hat, weil er meinte darin sein ein Virus. Von dem Hersteller gab es auch lediglich ein Entschuldigung... Microsoft gibt nur Patches heraus ohne Entschuldigung.... Grüße Lars
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
modeng Ehrenmitglied V.I.P. h.c.
Beiträge: 7061 Registriert: 10.12.2003
|
erstellt am: 18. Mrz. 2004 16:03 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Moin, gewiss fehlerfreie SOftware wird es nicht geben es geht hier eigentlich um effektiv gravierende Bugs und vielleicht ware es besser nicht in Featuritis auszubrechen und lieber etwas weniger dafuer aber sorgfaeltiger. Der Druck auf die Programmierier wird dadurch erheblich gemildert was auch der Software selbst zu gute kommt - da sprech ich mal aus Erfahrung ... > Microsoft gibt nur Patches heraus ohne Entschuldigung.... na fein, dafuer sind sie wenigstens kostenlos auch ein Feature modeng Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
CreaTec Mitglied
Beiträge: 262 Registriert: 13.11.2002 Win7/64bit, Solid Edge ST5
|
erstellt am: 18. Mrz. 2004 16:45 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
|
BZIBTE Mitglied
Beiträge: 11 Registriert: 19.03.2004 Es gibt keine dummen Anwender, die Fehler machen, es gibt nur schlechte Software, die Anwenderfehler zulässt
|
erstellt am: 19. Mrz. 2004 08:18 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo SEler, wir haben bei uns in den letzten zwei jahren sehr detailiert analysiert wieviel Vorteile uns neue Versionen bringen und dann dagegen gerechnet wieviel Mehraufwand wir durch Bugs, Test, Versionswechsel usw. haben: Bei unseren 40 SE-Lizenzen bleibt bei uns trotz neuer Bugs, Realsewechseln, Schulungen usw. eine Einsparung von 2500 Stunden pro Jahr (Januar 2002 bis januar 2004). Insgesamt kommen zu diesen 2500 Stunden noch weitere Dinge hinzu, die wir aber nicht messen können. das sind Dinge die früher nicht möglich waren, jetzt aber als Funktion in SE drin sind. Diese Punkte werden leider in Statistiken oft falsch verstanden: in der Bewertung für v15 wird irgendwann drin stehen 200Stunden Mehraufwand für farbige Zeichnungen, ich hab aber in meiner SE Statistik nirgendwo eine Einsparung, da wir durch die neuen Features 500 Stunden bunte Bilder erzeugen aus der Marketingabteilung in die Konstruktion verlagert haben. Also trotz neuer Bugs, her mit neuen Versionen mit neuen Funktionen, wir können zwar nicht alle gebrauchen, aber einieg sidn auch für uns. Bei den Bugs müssen wir nur darauf achten, das die Bugs nicht die Arbeitsmoral untergraben. das ganze hier unter einem anonymen Namen, da es ja sein könnte das einer aus unserem Management dies liest und uns dann zwei Konstrukteursstellen streichen will. BZIBTE Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
elsbett Mitglied
Beiträge: 450 Registriert: 26.03.2002
|
erstellt am: 19. Mrz. 2004 09:08 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Hallo Grundsätzlich bin ich ja auch dafür, dass die Entwickler sich die Zeit nehmen sollen, neue Features auszureifen, und nicht zuviel Marketingdruck haben sollten. Dies ist sicher für die Qualität förderlich. Ich meinte mehr die streng rechtliche Verantwortlichkeit, welche meines Erachten nichts bringt. Die andere Seite ist eben die, dass wir SE bei uns in gewissen Bereichen voll an die Funktionsgrenzen ausreizen, und effektiv dankbar sind, wenn mit jedem Release diese Grenzen erweitert werden. Gruss Eru... ------------------ P4 1.8GHz, Win 2k, GeForce3 Ti 200, SE V14 SP 12 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
gunni Mitglied
Beiträge: 254 Registriert: 20.08.2000 Fujitsu-Siemens Celsius 460 P4 - 1,7GHZ 1GB RAM ATI Fire GL2 -------------------- Windows2000 SP4 Solid Edge V16 SP4 -------------------- Solid Edge - Zusatztools: siritec.com - myNu 4.1 siritec.com - PMTabelle V3.0.0 siritec.com - DraftScale V1.0 siritec.com - MakroToolbar V1.0.0
|
erstellt am: 19. Mrz. 2004 15:41 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Unsere Erfahrungen mit dem "Attribute Replication problem": Seit beginn Umstellung auf die V14 (wir sind mit Update 4 eingestiegen) haben sich unsere Anwender über deutlich längere Ladezeiten von grossen Baugruppen gegenüber der V12 beschwert. Wir haben leider sofort nach erscheinen die Updates 9 und 10 eingespielt. Demnach hatten wir das "Attribute Replication problem" am Hals. Es ist der bisher grösste "Schnitzer" den sich die Programmierer von Solid Edge, seit dem wir dabei sind, geleistet haben. Das Kriesenmanagment ist dabei katastrophal. Auf den offizielle Solid-Edge-Seiten steht kein Wort dazu was man machen soll. Nur im EDS-Solid-Edge-Forum wurde dazu was gesagt. Wir haben erst am 20.02. von unserem Reseller eine Warnung erhalten dass es Probleme mit SP 9+10 gibt. Das Zapper-Tool und SP11 sind aber schon eine Woche früher erschienen. Meine Lehre daraus: Lieber etwas länger warten mit dem Updaten. Als Update 11 erschien habe wir es ebenfalls sofort draufgespielt und über alle Daten (ca.5000) das Zapper-Tool-V1 laufen Lassen. Das Zapper-Tool-V1 hat ca. 200 "infizierte" Dateien gefunden und bereinigt. Nebenwirkung: Ein paar Rohr-Parts die mit X-Press-Route erstellt wurden waren danach kaputt und ein paar aus STEP importierte Parts, die aus einem Body-Feature bestanden waren ebenfalls kaputt. Mich hat ein Solid-Edge-User kontaktiert, der mit massiven Problemen kämpft, extrem lange Ladezeiten von Baugruppen. Er hat herausgefunden dass in seinen Part-Dateien teils hunderte von "SEMismatchAttrDef"-Einträge vorhanden sind. Man kann diese ganz leicht finden, einfach die par- oder psm-Datei in einem Text-Editor öffnen und nach dem Wort "SEMismatchAttrDef" suchen. Diese Einträge befinden sich im "Parasolid-Abschnitt" der Datei. Er wollte von mir wissen ob wir auch diese Einträge in unseren Dateien haben oder ob er der einzige ist. Er habe bis zu 28410 "SEMismatchAttrDef"-Einträge pro Datei. Wir haben diese Einträge ebenfalls in unseren par- und psm-Dateien (bis zu 172 "SEMismatchAttrDef"-Einträge pro Datei). Vereinzelt auch in pwd-Dateien. Obwohl über alle Dateien schon das Zapper-Tool glaufen ist! Die Einträge sind auch schon in Dateien vorhanden die mit V14 Update 4 erstellt wurden und seit dem nicht mehr bearbeitet wurden. Also nicht erst seit Update 9 oder 10. Habe folgendes Probiert: Teil mit V12 SP 10 erstellt, in V14 SP 11 geöffnet und ohne was zu ändern gespeichert. Die Datei enthält daraufhin "SEMismatchAttrDef"-Einträge. Das Problem taucht also erst seit V14 auf, aber nicht erst seit Update 9 sondern schon früher (s.o.). Das Problem ist auch nicht mit Update 11 und dem Zapper-Tool behoben worden. Weitere Feststellung: Das "zapper_tool_V4" findet und bereinigt die Dateien auch nicht von den "SEMismatchAttrDef"-Einträgen. Nur ein öffnen und speichern der Dateien mit V14 Update 12 entfernt die "SEMismatchAttrDef"-Einträge aus den Dateien. Folgendes Habe ich festgestellt: Dateigrösse: 1259KB, 172 "SEMismatchAttrDef"-Einträge. Abspeichern mit V14 Update 12, Dateigrösse: 612KB, keine "SEMismatchAttrDef"-Einträge mehr. Das ist Faktor 2! Weiteres Beispiel: Das Platzieren von Ansichten einer mittleren Baugruppe dauerte extrem lange (ca. 10Minuten). Öffnen und abspeichern aller Einzelteile der Baugruppe mit V14 Update 12. Danach dauerte das Platzieren von Ansichten nur noch ca. 2Minuten. Meine persönliche Erfahrung: Finger weg vom Zapper-Tool. Dateien in SolidEdge V14 Update 12 öffnen und Speichern, das ist sicherer.
@Lars, das "Problemchen" bremst massiv Solid Edge V14 aus, beim einen mehr beim anderen weniger. Mehr nicht. Und was wünschen wir uns täglich? Mehr Performance, schnellere Rechner und dann kommt so was...
Grüsse Gunni
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
modeng Ehrenmitglied V.I.P. h.c.
Beiträge: 7061 Registriert: 10.12.2003
|
erstellt am: 19. Mrz. 2004 18:49 <-- editieren / zitieren --> Unities abgeben: Nur für Junix
Moin, richtig, fast alle Dateien, die mit V14 SP6 erstellt wurden haben das 'SEMismatchAttrDef'. Dateien die mit V12 erstellt wurden haben dies nicht. Wir wurden von unserem Reseller zu keiner Zeit auf dies Problem aufmerksam gemacht. Immerhin sind die Lizenznehmer UGS bzw. dem Reseller ja bekannt und eMail ist auch nicht erst gestern erfunden worden :-( Was auch noch stoerend ist, dass zum Teil alte Refererenzen auf Exceldateien in epischer Breite noch in .par Dateien sind obwohl weder der Rev.-Mngr sie auffuehrt noch sie im Status/Link/Binder zu sehen sind; auffindbar nur per Hex-Editor modeng Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|