---

Allgemeine Rundfrage:

Wir haben permanent zwischen 20 und 30 User aktive SWX-User im Einsatz.
Über einen speziellen Meldedienst erreichen mich pro Tag zwischen 5 und 10 Systemabstürze im Zusammenhang mit SWX.
Eine häufige Meldung ist:
Die Anweisung in "0x031blabla" verweist auf den Speicher in "0x000000B".
Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Klicken Sie auf.....bla bla... 

Bisher konnte mir keiner sagen, wo hierfür evtl die Ursachen zu suchen sind.
Die Meldung kommt bei den unterschiedlichsten Aktionen.

Zu unserem System:
SWX2001-SP14, Compaq-Rechner, MaxxDB mit Oracle, Novell-Server, Netzwerk 1GBit

Was sind mögliche Ursachen?
Wieviel Abstürze pro Tag und User werden überhaupt von anderen Anwendern toleriert? 

Danke im Voraus für das Feedback 

F.Herrmann

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

---

Hallo F.Herrmann,

Vom Anwender toleriert? Kein einziger.
Was ich für zumutbar halte? Ist ein anderes Thema.

Die Abstürze im Zusammenhang mit SolidWorks sind meiner Erfahrung nach 30% im Zusammenhang mit Grafikkarten und deren Treibern, 30% Konfiguration von Windows und dessen gesamten Netzwerk-Umfeld, 20 % Hardwareprobleme, 10 % Zusammenspiel der Programme untereinander, 8 % korrupte Daten und nur 2 % reproduzierbare Abstürze aus SolidWorks heraus.

Es gab gerade vor kurzem einen sehr guten Troubleshooting-Guide in comp.cad.solidworks (siehe http://groups.google.com/groups?q=Troubleshooting+a+crash-prone+system+group:comp.cad.solidworks ), aber der ist leider in englisch. Ich arbeite zwar an einer ähnlichen Checkliste, aber das dauert noch etwas.

Interessante Frage wäre: wie viele Abstürze bekommst du von diesen ganzen Usern, wenn nicht mit SolidWorks gearbeitet wird? Wenn dass MaxxDB Add-In ausgeschaltet wird? Wenn ihr auf den Novell-Server verzichtet? Habt ihr Dongle? Welche Windows Version (die Angabe fehlt leider)? Sind es immer dieselben Daten? Sind es immer dieselben User? Gleicher User andere Maschine auch Abstürze? Usw. usw. usw.

Aber akzeptiert hat noch nie jemand auch nur einen Absturz pro Monat ... 

Ciao,
Stefan

------------------
--
Inoffizielle deutsche SolidWorks Hilfeseite
http://solidworks.cad.de

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

---

Hallo Stefan,

die Sache mit der Checkliste klingt Supergut.

Zu deiner Antwort:
Auf den PC's wird fast ausschließlich konstruiert. Mit EXCEL, Word und Co. ist mir kein einziger Absturz bekannt.
Ab und zu wird mit ME10 gearbeitet, da gibt's ab und zu mal einen Hänger, aber da ist die Ursache bekannt.
Die MaxxDB ausschalten geht nicht. Wir arbeiten im Produktivbetrieb nur mit der Datenbank.
Auf den Novell-Server verzichten geht auch nicht. Da liegen unsere Daten drauf.
Zum Dongle: Wir haben einen License-Server mit Floating-Lizenzen.
Zur Windows-Version: Größtenteils NT. Ein paar mit Win2000, die wir jedoch wieder auf NT umstellen. Win2000 hat sich beim Schreiben auf den Novell-Server als Bremse herausgestellt.
Zu den Daten: Es sind die unterschiedlichsten Baugruppen, Teile und Vorgänge.
Gleicher User-andere Maschine: Haben wir auch schon versucht (Erst letzte Woche). Der User hatte auf der anderen Maschine an dem Tag nur 1 Absturz, statt vorhergegangender 5 auf seiner eigenen Maschine. Nur - was sagt uns das?
Das Problem ist einfach, daß man in dem gesamten SWX-Umfeld jede Menge Ressourcen binden kann - nur mit Untersuchungen, Kompatibilitätstests, Optimierungsmaßnahmen und Fehlersuche.

Aus meinem Veteranenleben - damals im Krieg...: Ich komme aus der Medusa-Szene (auf SUN), habe später mit HICAD gearbeitet (NT). Bei beiden Systemen wurde der 3D-Teil genutzt (Natürlich anderes 3D wie SWX - aber immerhin...).
Jedoch solche Probleme wie jetzt mit SWX hatte ich noch nie.
Und die Sache mit dem Akzeptieren: Man kann sich zwar über jeden Absturz aufregen, diesen auch dem Reseller mitteilen. Aber in einem Betrieb unserer Größenordnung bist du dann einen Großteil der Zeit nur beschäftigt mit weiterleiten und dokumentieren von Fehlerberichten. Zwischendrin muß ich ab und zu mal was arbeiten. Wie gesagt - wir haben 5-10 Abstürze am Tag.
Was bleibt also anderes übrig, als eine gewisse Anzahl von Abstürzen zu tolerieren? Es ist nicht mein Job, den Hersteller ständig auf irgendwelche Bugs aufmerksam zu machen. Wir haben ein Produkt gekauft, von dem wir erwarten, daß es stabil läuft. Meistens tut es das ja auch...aber leider nur meistens...

Vielleicht liegt es auch an der Größenordnung unserer Baugruppen. Wir bearbeiten mittlerweile Baugruppen mit über 3.500 Komponenten. Und dabei ist zu beobachten - je größer die Baugruppe - desto größer die Absturzrate. Dies ist die einzige erkennbare Regelmäßigkeit bei unserem Absturzproblem. Gibt es da Erkenntnisse bei anderen Anwendern?

Jedenfalls warte ich mal gespannt auf die Checkliste. Vielleicht können wir da ein paar neue Ansatzpunkte finden um einem Teil der Problematik auf die Spur zu kommen.
Alle werden wir sicher nicht ausräumen, da selbst unser Reseller darauf hinwies, daß man mit ca. 1-2 Abstürzen pro Woche rechnen muß. Dies läge jedoch an Windows. Na ja....das hilft uns weiter 

Also dann ... in freudiger Erwartung...
Frank Herrmann

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

---

HI Herrmann,

also wir hatten vor ca. nem halbem bis 3/4 jahr auch sehr viel mit Abstürzen zu arbeiten. Damals noch WInNT jetzt Win2k, es hatte viel mit unseren Normteilebibliothek zu tun, der Varbox. Aber jetzt sind eineige Bugs behoben und es sieht aus als würden die Abstürze weclhe wir jetzt noch haben nicht mit der Varbox in Verbindung stehen.
Seit wir Win2k drauf haben hat sich die ganze Situation etwas normalisiert, so im Schnitt 1-2 Pro Arbeitsplatz/pro Woche...
MAnche haben auch keine mehr .... wir haben auch grosse BG mit 2000-3000 Teilen.

Unsere rechner sind 800 Pnetium mit 512RAM und ner ELSA Gloria II.
Woher nun die Abstrürze rühren ?? may be Windows oder..... aber wie du sagst man muss auch noch was arbeiten nebenher, nicht nur analysieren......

in diesem Sinne frohes schaffen

CU Alexis

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

---

Hallo Frank,

> Die MaxxDB ausschalten geht nicht. Wir arbeiten im Produktivbetrieb nur mit der Datenbank.

Ja, ist logisch, sonst hätte man das ja nicht. Wir haben bei uns festgestellt, dass die Stabilität zunimmt, wenn wir das Add-In des PDM-Systems entladen, da im Hintergrund ansonsten ständig mit der Datenbank kommuniziert wird (soll es ja auch, aber bedeutet eben mehr Prozesse, die kreuz und quer mit- und manchmal gegeneinander arbeiten).

> Auf den Novell-Server verzichten geht auch nicht. Da liegen unsere Daten drauf.

Okay, Server auf dem die Daten liegen haben wir logischerweise auch. Aber eben nicht Novell ... das kam bei unseren Server-Spezies u.a. aus Stabilitätsgründen (!) nicht in die Tüte.

> Zum Dongle: Wir haben einen License-Server mit Floating-Lizenzen.

Schade, eine häufige Ursache für instabiles System ist der blöde Dongletreiber bzw. unglücklich konfigurierte LPT-Ports im BIOS.

> Zur Windows-Version: Größtenteils NT. Ein paar mit Win2000, die wir
> jedoch wieder auf NT umstellen. Win2000 hat sich beim Schreiben auf
> den Novell-Server als Bremse herausgestellt.

Jetzt weißt du was ich mit dem Novell-Server meine  Gerade die Speicherverwaltung ist unter Win2000 SP2 (wichtig!) deutlich besser als unter NT, noch besser nach ersten Aussagen verschiedener befreundeter Unternehmen mit XP. Gerade wenn ihr mit Dokumenten arbeitet, die viel Speicher brauchen ist das sehr wichtig. Siehe auch weiter unten.

> Zu den Daten: Es sind die unterschiedlichsten Baugruppen, Teile und Vorgänge.

Also keine korrupten Daten.

> Gleicher User-andere Maschine: Haben wir auch schon versucht (Erst
> letzte Woche). Der User hatte auf der anderen Maschine an dem Tag
> nur 1 Absturz, statt vorhergegangender 5 auf seiner eigenen
> Maschine. Nur - was sagt uns das?

Das die Umgebung auf der zweite Maschine wohl stabiler ist! Also wahrscheinlich nicht SolidWorks sondern Hardware oder Systemumgebung. BTW, arbeitet ihr mit Roaming profiles oder hat der Benutzer an der anderen Maschine ein neues Login bzw. Profil bekommen? Dann kann es ja auch noch an irgendetwas in der Userumgebung (oder auch z.B. SolidWorks-Einstellungen) sein.

> Das Problem ist einfach, daß man in dem gesamten SWX-Umfeld jede
> Menge Ressourcen binden kann - nur mit Untersuchungen,
> Kompatibilitätstests, Optimierungsmaßnahmen und Fehlersuche.

Ja, ich weiß, was du meinst. Hat aber nicht nur mit SolidWorks zu tun, sondern einfach mit der immer komplexeren Umgebung, in der alles zusammenspielen muss.

> Ich komme aus der Medusa-Szene (auf SUN).
> Jedoch solche Probleme wie jetzt mit SWX hatte ich noch nie.

Hey, hier treiben sich recht viel MEDUSA-Veteranen herum, bin auch einer (12.2.4 eingefroren auf DEC Unix und DEC Ultrix). Und ich stimm dir auch hier zu, wir haben bei weitem nicht diese Anzahl Abstürze wie im Windows-Umfeld. Die Fallen, die man im Laufe der Jahre alle herausgetüftelt hat (und da gab es einige), sind mittlerweile bei allen Usern bekannt und niemand tritt mehr freiwillig drauf oder beklagt sich zumindest anschließend nicht. Zumindest bei uns wurden die Anwender auch wesentlich intensiver auf einem deutlich weniger komplexen System geschult, damit sie eine Idee davon hatten, was man tun und was man lassen sollte.

Und das Wichtigste: auf der blöden Ultrix-Büchse lief das Betriebssystem mit ein paar Mounts von einen anderen Unixserver, das MEDUSA als 2D CAD und das war es dann! Kein Mail, keine Tabellenkalkulation, kein Schreibprogramm (ich konnte den Leuten einfach nicht die Eleganz und Sinnhaftigkeit von VI begreiflich machen  ), kein Datenaustausch mit Disketten, kein Internet, keine SAP-Anbindung, keine Datenbank für die Zeichnungsverwaltung, keine bunten Fenster, keine Hintergrundbilder, keine neue Grafikkarte alle 6 Monate oder Treiberupdates im Stundenrhythmus.

Ist für mich logisch, dass das stabiler läuft.

> Was bleibt also anderes übrig, als eine gewisse Anzahl von
> Abstürzen zu tolerieren?

So hab ich das auch gemeint. Wenn ich mehr Energie darein stecke mich aufzuregen als einfach neu zu starten und weiterzumachen ... tolerabel. Wenn ich weiß, dass ein bestimmter Weg nur schlecht oder gar nicht funktioniert und mir jemand einen Weg drumherum zeigt ... dann sollte ich nicht drauf bestehen, dass ich den Weg durch die Mauer aber nun mal gehen will. Oder zumindest anschließend nicht über blutige Nase rumjammern.

> Es ist nicht mein Job, den Hersteller ständig auf irgendwelche Bugs
> aufmerksam zu machen. Wir haben ein Produkt gekauft, von dem wir
> erwarten, daß es stabil läuft. Meistens tut es das ja auch...aber
> leider nur meistens...

Das seh ich allerdings etwas anders. Es ist nicht mein Job ... okay, es hilft dem Hersteller und es hilft mir, wenn er es weiß um eine Lösung zu finden. Ein Problem zu erkennen ist so viel schwieriger als es zu beheben ... und wenn ich eine Win-Win-Situation habe werde ich diese sicher nutzen.

Nun kann man natürlich manchmal in Zweifel geraten, ob auch ein Gewinn auf Seiten des Anwenders vorliegt. Meine persönliche (und nicht gekaufte) Meinung ist: ich fühle mich bei meinem Vertriebspartner gut aufgehoben, sie sind engagiert und versuchen zu helfen, wo es geht. Die Leute, die ich von SolidWorks kennengelernt habe, sind mit Herz bei der Sache, sie leben und leiden für und mit ihrer Software, etwas, was man im amerikanische "passion" nennt und für das es keine vernünftige Übersetzung gibt. Das gilt für den neuen Programmierer genauso wie für den Entwicklungsleiter. Ich habe das Gefühl, dass ich als Kunde wichtig bin und das man mir Aufmerksamkeit schenkt.

Ich finde die Informationspolitik schlecht und wünschte mir häufig mehr offizielle Statements zu Weiterentwicklung, Prioritäten usw. , aber es ist mir um Klassen lieber als z.B. die Infopolitik von CV (wenn du MEDUSA hattest, weißt du was ich meine   )

Ich ärger mich auch gelegentlich über SolidWorks und sag das dann auch (   Richard, Christian, Frank und wer sonst noch auf der CEBIT das von SolidWorks jetzt liest und grinst ) aber wenn ich mir unsere Liste mit Fehlermeldungen und Verbesserungsvorschlägen seit 1997 anschauen sehe ich wesentlich mehr erledigte als offene Punkte (denn die vermehren sich auch irgendwie   ). Und das sind Punkte, die IMHO für SolidWorks sprechen.

> Vielleicht liegt es auch an der Größenordnung unserer Baugruppen.
> Wir bearbeiten mittlerweile Baugruppen mit über 3.500 Komponenten.
> Und dabei ist zu beobachten - je größer die Baugruppe - desto
> größer die Absturzrate. Dies ist die einzige erkennbare
> Regelmäßigkeit bei unserem Absturzproblem. Gibt es da Erkenntnisse
> bei anderen Anwendern?

Aaaaah, jetzt kommst du mit dem wichtigen Punkt. Jupp, Speicherverwaltung am Limit kann WIndows nicht besonders gut. Falls Windows 2000 unbedingt SP2 einsetzen. Falls NT4 gibt es eine inoffizielle ole32.dll (die eigentlich mal im SP7 zu NT kommen sollte), mit der Speicherprobleme bei diesen Dimensionen geringer werden sollen. Sprich mal deinen Vertriebspartner oder SolidWorks direkt an und frag nach dieser DLL (ich möchte das nicht so einfach weitergeben, da alles sehr inoffiziell). Und wenn ihr experimentierfreudig seit versuch mal XP.

Ciao,
Stefan

------------------
--
Inoffizielle deutsche SolidWorks Hilfeseite
http://solidworks.cad.de

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

---

[QUOTE]Original erstellt von Herrmann:
[B]Allgemeine Rundfrage:

Eine häufige Meldung ist:
Die Anweisung in "0x031blabla" verweist auf den Speicher in "0x000000B".
Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Klicken Sie auf.....bla bla... 

Hallo Herrmann,
wir hatten ein ähnliches Verhalten auf einem unserer Rechner (Identische Fehlermeldung) . Nach Austausch des Virenscanners gabŽs dann keine Probleme mehr.

Reiner Kober

------------------
-----------

Mit freundlichem Gruß
keytech

www.keytech.de

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

---

Zitat:

---

Original erstellt von Herrmann:
Allgemeine Rundfrage:

Eine häufige Meldung ist:
Die Anweisung in "0x031blabla" verweist auf den Speicher in "0x000000B".
Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.
Klicken Sie auf.....bla bla... 

---

Hallo Hermann,
wir haben ähnliche SWX-abstürze. Reduziert wurden sie mit regelmäßigem löschen im Temp-Sicherungsverzeichnis. Auch der Virenscanner von LotusNotes kann zu Absürzen führen (Deshalb wurde er bei uns ausgeschaltet). Wir sind momentan auf einem Stand von ca. 0-2 Abstürze die Woche pro Anwender. Ist O.K. Allerdings würde es mich auch einmal interessieren, worin die genaue Problematik bei den Abstürzen liegt (Nur ein RAM-Problem oder steckt mehr dahinter???)!!

Vielleicht hilft Dir das ein bißchen weiter. 

MfG
Andy

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

---

Hallo Hermann,

ich hatte vor kurzem eine Kiste (= alter PC) zum rumbasteln und hab da mal die SWX-Demo draufgespielt.

Danach einige Teile und 'ne Baugruppe erstellt.
Dabei Stück für Stück den Speicher reduziert. Bin runter gegangen bis unter die empfohlene Mindestgröße. Bei 64 MB hab ich dann das grausame Spiel beendet.

Ergebnis war eindeutig: Je weniger Speicher, um so mehr Auslagerung und um so mehr Abstürze.

Grüße
Markus

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

---

Hi @ll,

tja @macki, daß würde dann wohl unsere "geringe" Abstürze erklären.
System: Pentium 4 1,5Ghz, 1024MB RDRam, ELSA Gloria II, Netz 1GB und fettgroße Festplatte.  Leider aber noch auf SW2001 SP14. 

Tschü
Andy 

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

---

      Danke, Danke, Danke,....      

Ich bin einigermaßen überrascht, daß das Thema doch eine gewisse Aufmerksamkeit bewirkt.
(Ich entnehme das mal u.a. der Hit-Anzahl)
Es beruhigt mich etwas, daß wir nicht die einzigen sind, die mit dem Thema zu kämpfen haben.
Es sind bisher einige interessante Ansätze in den Beiträgen, die es wert sind, daß man sie näher untersucht.

Ich fasse zusammen:
        Das Thema Novell muß nochmal unter die Lupe genommen werden
        In diesem Rahmen auch nochmal über Win2000 nachdenken
        Der Geschichte mit "inoffizielle ole32.dll" mal nachgehen
        XP in Erwägung ziehen
        Die Virenscanner mal abschalten
        LotusNotes mal abschalten
        Die Speicher aufrüsten.
        Normteile (Betrifft uns nicht-wir haben eigene Schrauben      )
        Dongletreiber bzw. unglücklich konfigurierte LPT-Ports im BIOS - Fehlanzeige

        Die berufliche Perspektive für die nächsten Tage ist gesichert       

Also nochmals.......
Muchas gracias für die Tipps     

(Stefan... Die Welt fiebert nach deiner Checkliste...)

[Diese Nachricht wurde von Herrmann am 14. März 2002 editiert.]

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

---

Wir setzen SWX 2001+ SP0.0 ,Win 2000 Sp2, 1000 Mhz Dual Pentium auf Asus Board mit Elsa Gloria 3 (neueste Treiber von Nvidia)und 512Mb Ram.Wir haben Abstürze auch bei kleineren Baugruppen (10 parts)gehabt.
Allerdings erstmals um die Mittagszeit (zu heiß?)(Speicher überlauf?).
Heute morgen um 6Uhr versagte SWX? schon nach einer Stunde Arbeit beim rotieren des parts in die Vorderansicht über die Schaltfläche vorherige Ansicht.

Die Fehlermeldung lautete "Solid Works verursachte einen Fehler..."

In den Logdateien war folgendes

  "Absturz beim drehen
    kommt vor beim wiederherstellen der letzten Ansicht , Zoom 
    auf Vorderansicht , rotieren mit mittlerer Maustaste"

Die letzten Aufzeichnungen aus der performance.log

<DOC_TIME> "D:\sw_zeichnungen\2002\02_200er_Backen_Rohrpresse94\Distanzklotz_2.SLDPRT" 2586.078000
<EXCEPTION> "Access Violation at 0ec5a3c8 (virtual address 00000000), attempt to read from memory";
<UNHANDLED>
T=2777;I=0;<F>

Die letzten Zeilen aus swxjrnl.swj

Part.ActiveView().RotateAboutCenter -0.00538999, 0
Part.SelectByID "", "FACE", 0.08202517253858, -0.06783578643751, -0.2895687424803
Part.SelectByID "", "FACE", 0.08202517253858, -0.06783578643751, -0.2895687424803
Part.OpenCompFile
swApp.LoadFile2 "D:\sw_zeichnungen\2002\02_200er_Backen_Rohrpresse94\Klemmleiste 200_25.SLDPRT", ""
Set Part = swApp.ActiveDoc
Set Part = swApp.OpenDoc4 ("D:\sw_zeichnungen\2002\02_200er_Backen_Rohrpresse94\Klemmleiste 200_25.SLDPRT", 1, 0, "", longstatus)
swApp.ActiveDoc.ActiveView.FrameLeft = 0
swApp.ActiveDoc.ActiveView.FrameTop = 0
swApp.ActiveDoc.ActiveView.FrameState = 1
Set Part = swApp.ActivateDoc ("Klemmleiste 200_25.SLDPRT")
Part.ClearSelection
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0126386
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0252772
Part.ActiveView().RotateAboutCenter 0, -0.0126386
Part.ActiveView().RotateAboutCenter 0, -0.0252772
Part.ActiveView().RotateAboutCenter 0, -0.0126386
Part.ActiveView().RotateAboutCenter 0, -0.0252772
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0126386
Part.ActiveView().RotateAboutCenter 0, -0.0063193
Part.ActiveView().RotateAboutCenter 0, -0.0063193

Deutet das auf Fehler im Speicherzugriff durch Win oder der Grafikkarte. (Habe schon mit Software OpenGL versucht- stürzt
dann auch beim speichern der Datei bzw. umschalten von einem zum anderen Fenster ab.

Michael

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

---

Hallo Stefan,

zu:
inoffizielle ole32.dll (die eigentlich mal im SP7 zu NT kommen sollte

Welche Version ist da gemeint, ohne Versionsnummer ist die nicht zu finden?

wir haben eine v4.00, 16.6.2001 , 701200 bytes groß .. die ist quasi SP7 (kommt aus dem Security RollupFix Post SP6a, der inoffiziell SP7 heisst)

Meinst du diese?

Gruß Bernd

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

---

Die ich geschickt bekommen habe ist 700.688 Bytes groß und hat die Dateiversion 4.0.1381.7086

Ich hab die selbst aber noch nicht einsetzen müssen, da wir bisher noch nicht derartige Monster haben.

Ciao,
Stefan

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

---

Hallo!
Es stellt sich die Frage nach der Version der MaxxDB. Bis 2.9 hat sie ein Fehler beim Struktur regenerieren.
Bei der Version 3 soll dies behoben sein.
Wir gehen allerdings über die ODBC Schnittstelle

Gruss Martin

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

---

Hallo Martin

Der Tipp klingt im Ansatz sehr gut. Wir haben Version 2.291.

Offiziell gibt es glaube ich erst Version 2.29.
Meinst du die?

Und woher hast du die Info? Ich stehe nämlich gerade in regem Kontakt mit "Herrn MaxxDB-himself". Er hat diesbezüglich noch nie was erwähnt.

Gruß Frank

[Diese Nachricht wurde von Herrmann am 18. März 2002 editiert.]

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

---

Ähm Ja stimmt! 2.29

Woher? Von meinem Reseller!

Die hatten noch einen Kunden bei dem es Abstürze gibt. Diese meldeten es dann weiter.

Gruß Martin

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

---

okay, Danke, werde das mal prüfen

Gruß Frank

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

---

Hallo,

wir haben auch öfters Probleme mit grossen Baugruppen (bis 1000 Teile), die Abstürze könnten auch eine Speicherproblem sein. Daher wäre ich stark an der DLL interessiert, könnten Sie mir diese zusenden ?
Obwohl nur 50% des Arbeitsspeichers benutzt wird, erhalten wir die Meldung dass der Arbeitspeicher voll ist ????

danke und gruss,
PAtrick

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

---

Hallo!
DA es sich um eine allgemeine Umfrage handelt geb ich meinen Senf auch noch dazu ab:

Wir haben ganz viele SWX-Workstations und seitdem wir auf W2K Sp3 sind haben wir nur noch etwa 10% der Abstürze im Vergleich zu NT. Darüber sind wir sehr froh  .
Natürlich sind diese 10% immer noch zuviel, was uns sehr traurig macht  , aber wir sind auf dem richtigen Weg. Auf unseren Büchsen läuft so ziemlich alles, was einem das Leben schwer machen kann (SAP, Smarteam, Oracle etc.) und jede Menge Spezialsoftware auf die der Einzelne nieundnimmer verzichten kann.
Mir ist aber aufgefallen, dass wenn SolidWorks ein paar mal abraucht auch W2K kleine Probleme kriegt. In solchen Fällen lösche ich auf den Maschinen immer ALLES was irgendwie nach TEMPORÄRer Datei aussieht, und zwar ohne Rücksicht auf Verluste und das freut dann den einen oder anderen User überhaupt nicht und ich muss mich verstecken, aber es hilft zu 99%. WennŽs dann immer noch nicht geht, setzen wir die Teile neu auf und lassen uns den Rest vom Tag nicht mehr blicken

------------------
Grüße von der Saar
Uwe Blum

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