| | | 3D-Druck: 7 Gründe für den Einsatz in der Medizin, ein Fachartikel
|
Autor
|
Thema: Schlechte Performance 2014 R2 und seltsames verhalten der OLDB.MDB (3206 mal gelesen)
|
g.r.k. Mitglied
Beiträge: 29 Registriert: 06.06.2012 ecscad professional 2019 64-Bit Ver. 19.3.2.## SR 3.2 eXs 2021 FR7-1 + eXs 2022 FR2-1
|
erstellt am: 01. Apr. 2014 13:59 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen Bei uns wurde letzte Woche ecscad 2014 R2 Hotfix 1 installiert. (Bis anhin haben wir mit 2012 SP 1 gearbeitet.) Leider muss ich sagen, dass die Performance deutlich schlechter geworden ist!! Projekte bearbeiten wir mittels check in/out. (Projekt lokal, ArtikelDB + SymbolDB nicht, die bleibt auf dem Netz) Die Bedienung des Programmes fühlt sich zäh an. Alles dauert etwas länger als vorher mit ecs 2012. Immer wieder braucht das Programm nach ausführen einer Aktion kleine Denkpausen welche die Maus "hängen" lassen. Beim einfachen Seitenwechsel kommt es manchmal zu längeren Wartezeiten von mehreren Sekunden etc. Je grösser das Projekt, umso schlimmer scheint es zu sein. Die von Wassermann73 beschriebenen Probleme kann ich 1:1 bestätigen. Manchmal dauert das simple ändern einer BMK oder eines Potential-Querverweis über 10sek! Das Programm reagiert während diese Zeit natürlich nicht mehr. So macht der Umstieg von ecs 2012 auf 2014 trotz diverser verbesserter Funktionen wirklich keinen Spass! An der Infrastruktur oder Konfiguration kann das wohl nicht liegen, ist ja alles wie vorher unter ecscad 2012 eingerichtet. Auch an der Hardware wurden keine Änderungen vorgenommen Die oldb.mdb legt (zumindest bei uns) unter ecscad 2014 ein seltsames verhalten an den Tag.
Es reicht, ein Projekt einzuchecken und zu öffnen: Obwohl das Projekt nicht bearbeitet wird, vergrösert sich die OLDB.MDB alle 15 sek um 24 kB! Das heisst, nach 15 minuten ist das Projekt einfach mal 1MB grösser, ohne dass auch nur ein Strich geändert wurde. Versuch: Projekt geöffnet, OLDB.MDB 7.6 MB. Das Projekt nicht weiter bearbeitet. (Noch nicht einmal im Projekt Navigiert) Nach 3 Stunden ist die OLED.MBD auf über 16 MB angewachsen! Anderer Versuch: Ein Projekt von 2011 mit einer Grösse von 7 MB eingecheckt, geöffnet und reorganisiert. OLDB.MDB nach reorganisieren: ecscad 2012: 4.6 MB / ecscad 2014: 30 MB !!!! Das muss natürlich nicht zwingend etwas mit der schlechteren Performance von ecscad 2014 R2 zu tun haben. Es zeigt aber, dass einige 'Bugs' vorhanden sind, um die sich die Entwickler dringend kümmern sollten. Gruss g.r.k.
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Wassermann73 Mitglied Konstrukteur für Walzenlader (Dipl.-Ing. der Elektrotechnik)
Beiträge: 150 Registriert: 24.05.2006 Windows 7 Prof. ecscad 2017 Standalone 64bit.
|
erstellt am: 02. Apr. 2014 07:27 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Hallo, erstmal danke. Dies ist der erste Beitrag der das seltsame Verhalten bei uns bestätigt. Ich hoffe jetzt mal das es weitere User geben wird die das beobachten und hier veröffentlichen. Das Phänomen mit der oldb.mdb haben wir auch gesehen. Hier habe ich aber nicht weiter recheriert, da ich auch meine Arbeit mal schaffen muss und bin ja Konstrukteur und nicht EDV´ler, der sich den ganzen Tag mit derartigen Problemen befassen kann ;-). ------------------ Systemadmin Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
309556 Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 02. Apr. 2014 18:58 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Darf ich fragen welche Access-Version oder Runtime (bei der 2012, bzw bei der neune 2014R2) da im Einsatz ist? Da scheint der Compact/Repair der Access DB nicht zu greifen... Diese Verhalten ist in Access begründet und kann, mit Ausnahme des Compact Repair, nicht wirklich durch ecscad beeinflusst werden. Wer eine Vollversion des MSAccess im EInsatz hat kann nach dieser Vorgehensweise etwas optimieren... http://office.microsoft.com/en-001/access-help/compact-and-repair-an-access-file-HP005187449.aspx Das optimieren des DB Platzes kann bei jedem Scliessen der DB akitiviert werden: Das optimieren ist natürlich gesperrt solange eine anderer Benutzer auf die gleiche DB zugreift! Version 2007 - Öffne die Acces DB mit deiner Access Vollversion - im Tools Menü auf Optionen klicken - in den Tab General wechseln - und dann Compact Repair bei jedem Schliessen wählen Hier für die Versionen 2010 & 2013 - Öffne die Acces DB mit deiner Access Vollversion - unter Access Optionen - aktuelle Datenbank - beim schliessen komprimieren aktivieren So wird immer wenn möglich die sich selbständig aufblasende DB wieder in vernünftiger Grösse gespeichert. Ob das mit Beispielsweise der MSA-Runtime 2010 nach folgenden Muster geht, kann ich leider nicht bestätigen: (nach MS müsste das aber gehen) "C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE" /compact "V:\ACADecs2014R2DEx64\x64\acad\Manufacturer\AB\AB_ARTICLE.MDB" 8-tung: Pfadbeispiel einer reinen 64bit Umgebung... PS: in den 80er Jahren war es ein Argument für die Geschwindigkeit der mdb... und Platzprobleme hat man heute ja meist nicht mehr aber in den meisten Fällen müssen halt Unmengen an Datenpaketen durch den LAN-Schlauch
PPS: hoffentlich schaut sich das noch jemand beim Development an, ist aber vermutlich wieder so ne Sache dass es nicht mit allen Konstellationen hinzukriegen ist...
------------------ viel Erfolg und frohes Schaffen RePa Tolle Ideen, konstruktive Verbesserungsvorschläge, Stammdaten, AddOn's? Anregungen, UserVoice AutoCAD ecscad Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
g.r.k. Mitglied
Beiträge: 29 Registriert: 06.06.2012 ecscad professional 2019 64-Bit Ver. 19.3.2.## SR 3.2 eXs 2021 FR7-1 + eXs 2022 FR2-1
|
erstellt am: 03. Apr. 2014 09:01 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen Danke für eure Antworten
Zitat: Diese Verhalten ist in Access begründet und kann, mit Ausnahme des Compact Repair, nicht wirklich durch ecscad beeinflusst werden.
Da stellt sich mir aber die Frage, warum dieses Verhalten (mit dem aufblasen der DB) nur unter ecscad 2014 auftritt und unter ecscad 2012 nicht. Die bei meinen Versuchen eingesetzten ecscad Versionen sind ja beide auf demselben Rechner installiert und greifen auf dasselbe Access 2010 zu. Wenn das Problem am Access liegen würde und ecscad keinen Einfluss hat, müsste doch dieses Verhalten bei beiden ecscad Versionen gleich sein? Zitat: müssen halt Unmengen an Datenpaketen durch den LAN-Schlauch
Wir Arbeiten mit Check in/out, da liegt die OLDB ja Lokal auf Laufwerk C. Ob das aufblasen der DB etwas mit der schlechteren Performance von ecscad 2014 zu tun hat, kann ich natürlich nicht beurteilen, verdächtig ist es auf alle Fälle. Früher (ecscad 5.5) hatten wir alle Daten auf dem Netzlaufwerk. Bei der Umstellung auf ecs 2009 gab es auch mit der Performance Probleme, weshalb wir damals auf Check in/out umgestellt haben. Das hat geholfen. Mit ecs 2012 wurde die Performance sogar noch besser. Nun mit ecs 2014 fühle ich mich ins 2009 zurückversetzt, nur mit dem Unterschied, dass wir keine Verbesserung mehr vornehmen können, da wir bereits mit Check in/out arbeiten. Zitat: hoffentlich schaut sich das noch jemand beim Development an, ist aber vermutlich wieder so ne Sache dass es nicht mit allen Konstellationen hinzukriegen ist...
Heisst das übersetzt : Da die Entwickler eh schon mit ecscad 2015 beschäftigt sind, müssen sich die Kunden damit abfinden und können nur hoffen, dass die nächste Version besser wird?
Gruss g.r.k. [Diese Nachricht wurde von g.r.k. am 03. Apr. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
309556 Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 03. Apr. 2014 17:05 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
sorry, ich wollte eigentlich nur daruf hinweisen, dass es auch eine Frage der eingesetzten Access (Vollversion oder Runtime etc) sein könnte. Gebe dir natürlich voll Recht, aber kann dir versichern die Entwickler sind sehr gefordert alles optimal für alle Versionen effizient zu halten. Also nochmal die Nachfrage zu deine Access Umgebung, gehe nämlich schwer davon aus, dass sich AUCH da etwas in deiner Umgebung geändert hat und nur darauf haben meine Tipps gezielt ------------------ viel Erfolg und frohes Schaffen RePa Tolle Ideen, konstruktive Verbesserungsvorschläge, Stammdaten, AddOn's? Anregungen, UserVoice AutoCAD ecscad Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
309556 Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 03. Apr. 2014 17:06 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
|
g.r.k. Mitglied
Beiträge: 29 Registriert: 06.06.2012 ecscad professional 2019 64-Bit Ver. 19.3.2.## SR 3.2 eXs 2021 FR7-1 + eXs 2022 FR2-1
|
erstellt am: 04. Apr. 2014 14:33 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von 309556: ich wür generell nicht zu viel zwischen den Zeilen versuchen zu interpretieren, das Leben ist doch schon kompliziert genug
Alles easy, hab mein noch nicht verloren. Zum Thema: Betriebssystem Windows 7 Enterprise (64Bit) Access als Bestandteil von Microsoft Office Professional Plus 2010 (32Bit) An der Access Umgebung hat sich meines Wissens nichts geändert, ist unser Firmenstandard. Ecscsd wurde von unserem Vertragshändler installiert. Die Projekte, SymbolDBs usw wurden in einen neuen Pfad kopiert (sind also 2x vorhanden). Die Konfiguration ist nun so, dass ich Ecscad 2014 aber auch noch ecscad 2012 auf demselben Rechner nutzen kann. Es sind also beide Versionen in derselben Umgebung integriert. -Unter ecscad 2014 bläht sich das Projekt kontinuierlich auf, unter ecscad 2012 nicht. -Mit ecscad 2014 ist das Projekt nach dem reorganisieren 6x grösser als mit ecscad 2012. Dein Tipp zum komprimieren der DB funktioniert. Ist aber leider keine praktikable Lösung. (Sich bei jedem Projekt durch die Ordnerstruktur zur OLDB durchklichken und ihre Einstellungen ändern kanns ja auch nicht sein). Der Kern das Problemes ist doch, dass sie sich überhaupt aufbläht. Ob das ganze nun mit den Performance-Einbusse etwas zu tun hat, kann ich nicht beurteilen. Aber ich habe die möglichkeit, beide Versionen auf demselben System zu nutzen. Und da muss ich sagen, ecscad 2012 läuft einfach "flüssiger" als ecscad 2014. Gruss und ein schönes Wochenende g.r.k. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
309556 Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 04. Apr. 2014 16:29 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Bin ich aber froh :-) Deine Vollversion Access 2010 hast du nun so aktiviert, dass automatisch komprimiert wird? Das scheint nähmlich in der 2014 nicht automatisch zu geschehen, im Gegensatz zur 2012er Version. Das Aufblähen der DB ist eben eine Access eigene Geschichte, führt aber viel zu weit das hier zu erklären... Aber wie du festgestellt hast ist es eben AUCH eine Frage wie man damit umgeht oder eben umgehen kann PS: die übergrösse des Projektes kann noch andere Gründe haben: - es werden von jeder dwg bak's gezüchtet (das lässt sich ja easy kontrollieren) - es werden nicht benötigte dwf von jedem DWG erstellt (kein Vault im Einsatz) Beides drückt natürlich auch auf die Performance... ebenfalls en erholsames WE ------------------ viel Erfolg und frohes Schaffen RePa Tolle Ideen, konstruktive Verbesserungsvorschläge, Stammdaten, AddOn's? Anregungen, UserVoice AutoCAD ecscad Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
ZarkoM Mitglied
Beiträge: 3 Registriert: 18.04.2014
|
erstellt am: 18. Apr. 2014 12:10 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Sorry for writing in english, but my german is really bad. We also noticed very bad performance of ecscad 2014 R4 Hotfix 1. We compared copying of one drawing set from one project to other (empty project). The same procedure of about 70 pages of drawing set last 8:36 (eight minutes and 36 seconds) on ecscad2011 and 2:40:00 (two hours and forty minutes) on ecscad2014. All data was stored locally (no network involved). Later on we discovered (when copying several drawing sets with ActiveX API) that ecscad2014 crashes after copying 127 pages (when copying from one project to another) with error 3048 (can not open more databases) which occurs when more than 255 connections to MS JET database are simultaneously opened. That means that ecscad probably opens new connection for each new copied page and forgets to close it. Even if it would close it, it is extremly inefficient to open database for each page and this is probably one of the reasons for such a bad performance. As this doesn't happen with ecscad2011 I suspect that somewhere after ecscad2011 somebody at Autodesk/MuM changed internal interface to ms jet database which results in so bad performance. Regards, Zarko [Diese Nachricht wurde von ZarkoM am 18. Apr. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
309556 Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 18. Apr. 2014 12:48 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Thank you for your inputs, but... can you send us per PN your ecsinfo.txt (WORK-DIR) please? 2014R4 does not exist and never will ;-) And please don't to much speculate about the technics behind, there was changes driven by a clean x64 support of corse! Are you working on a single client or in a Network area? Singel use in Project or in a Team in the same Project? This errors acures also if you will copy exactly this pages witch a other college is working on exactly this base project Sorry to say that, but keep in mind that to often bad performance are locate in seamless Network areas. kind Regards René ------------------ viel Erfolg und frohes Schaffen RePa Tolle Ideen, konstruktive Verbesserungsvorschläge, Stammdaten, AddOn's? Anregungen, UserVoice AutoCAD ecscad Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
ZarkoM Mitglied
Beiträge: 3 Registriert: 18.04.2014
|
erstellt am: 19. Apr. 2014 00:39 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Thank you for your input I will provide ecsinfo.txt as soon I come to workplace (holidays :-)) 2014R4 was a typo: Ecscad 2014 R2 Hotfix 1 We have ecscad installed on a networked environment, but for this particular speed test, program and all project data was stored locally (C:\ drive). Licence was taken from a network server. Project was single used (one and only user was me). This is valid for test regarding speed (comparison ecscad2011 and ecscad2014). Regarding error 3048: We firstly noticed error in networked environment (ecscad2014 32 bit, data stored on network drive), it was clearly repeatable. Each of two drawing sets involved could be copied without any problem via user interface on a step by step basis, probably, as it took so much time -- I can not confirm that -- with restart of ecscad between each copy procedure. Later on we checked restore of the same projects involved on the local c:\ drive -- single user use (but licence over network) and it happened again on the exactly the same page of the second drawing set (copy via EcsCmdInstCopy). Error does not occur when copying from one drawing set (even if bigger than 129 pages) to another in the same project. In this case the speed of copying is also very much higher. It occurred only in case of copying from one to another project. I would do more tests, but as it takes more than 2 hours it is unacceptably time consuming. I very much know influences of network (data stored in network environment) and especially concurrent multi user use to software based (also) on MS jet technology, so I am trying to exclude that factors as much as possible when doing such tests. It is so bad that we can not avoid that by using ecscad in real production environment as our projects consist of several thousand pages and it is not possible to handle design work separately. regards Žarko [Diese Nachricht wurde von ZarkoM am 19. Apr. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
RePao Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 15. Jun. 2014 09:47 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
|
RePao Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 15. Jun. 2014 09:49 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
|
ZarkoM Mitglied
Beiträge: 3 Registriert: 18.04.2014
|
erstellt am: 16. Jun. 2014 14:13 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
Zitat: Original erstellt von RePao: what is the State by your situation? Did you find the time to use the additional HF?
Ho, René, It seems that HF2 solved performance problems related to OLDB handling. After we install it, we are finally getting performance results comparable to Ecscad 2011 Regards Žarko
[Diese Nachricht wurde von ZarkoM am 16. Jun. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
g.r.k. Mitglied
Beiträge: 29 Registriert: 06.06.2012 ecscad professional 2019 64-Bit Ver. 19.3.2.## SR 3.2 eXs 2021 FR7-1 + eXs 2022 FR2-1
|
erstellt am: 01. Jul. 2014 09:08 <-- editieren / zitieren --> Unities abgeben:
|
RePao Moderator 14e one 4 electric
Beiträge: 614 Registriert: 04.09.2004 Win10 x64 MSO2016 / MSO365 x64 ACAD, ACADM, AIP, PrDS ePlan P8 2.9, Zuken e3.Series 2020, EB 2019 ecscad 2019, eXs 2021/22 MS-SQL2019
|
erstellt am: 01. Jul. 2014 12:07 <-- editieren / zitieren --> Unities abgeben: Nur für g.r.k.
|
g.r.k. Mitglied
Beiträge: 29 Registriert: 06.06.2012 ecscad professional 2019 64-Bit Ver. 19.3.2.## SR 3.2 eXs 2021 FR7-1 + eXs 2022 FR2-1
|
erstellt am: 06. Aug. 2014 11:13 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen So, der HF2 ist nun bei uns seit 2.5 Wochen drauf. Die Performence gegenüber HF1 hat sich deutlich verbessert und die Bedienung von ecscad fühlt sich wieder so an wie vorher (ecscad 2012). OLDB bläht sich nicht mehr auf. Auch keine Abstürze mehr im Klemmeneditor gehabt. An die lieben ecscad Entwickler: warum den nicht gleich so? Gruss g.r.k. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|