---

Hallo,

ich habe da ein kleines Problem mit der Geschwindigkeit meiner Artikeldatenbank/Verwaltung.

Ein paar Infos:
-Arbeite mit einem relativ neuen Rechner
-EPLAN P8 2.8 HF2
-ca. 6 Lizenzen sind immer im Einsatz
-Keinen SQL-Server, sondern über Access (Office 2013)
-Datenbank .mdb liegt im Netzwerk auf die jeder Rechner zugreift

Wenn ich die Artikelverwaltung aufrufe über Dienstprogramme\Artikel benötige ich teilweise bis zu 20 Sekunden bis sich diese öffnet.

Das gleiche Problem, wenn ich den Artikel im Schaltplan ändern will und ich die Geräteauswahl aufrufe.

Ebenfalls wenn ich in den Artikelstammdaten einen Artikel suche.

Eine Lösung habe ich eigentlich schon gefunden.
---> Ich gehe auf Dienstprogramme\Artikel\Verwaltung\Extras --> Suchindex aktualisieren

Danach brauche ich anstatt 20 Sekunden zum öffnen der Datenbank nur noch unter 1 Sekunde.  

ABER !!!!!!!!

Nun hat mein Kollege das Problem, dass bei seinem Rechner das Aufrufen der Datenbank lange dauert. 

d.h. immer derjenige, der den Suchindex aktualisiert, bei dem läuft EPLAN flüssig...und die anderen schauen in der Zeit in die Röhre...       

Das Problem ist eigentlich erst aufgetreten, seit dem wir umgestiegen sind auf P8 2.8 .

FRAGE:

-Kennt das Problem vielleicht schon jemand? 
-Besteht die Möglichkeit, dass es mit einem SQL-Server besser läuft? 
-Gibt es vielleicht eine Einstellungssache, die ich übersehen habe, die bei allen Rechnern gleich sein muss? 

Ich hoffe mir kann jemand da draußen helfen  

[Diese Nachricht wurde von 3rnie am 07. Aug. 2019 editiert.]

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

---

Hallo,

Kurz vorab:
Eine dateibasierte Datenbank (Access) ist für den Multiuserbetrieb nicht wirklich effizient. Ich würde empfehlen das Thema SQL Express mal in Angriff zu nehme.

Zu dem Problem:
wie groß ist die Access Datenbank?
- Ich tippe auf 50-100MB. (Habe aber auch schon 2-3GB große EPLAN Artikelverwaltungen gesehen.)
--> Hier würde ich einmal eine neue Datenbank anlegen und per XML Export und Import alle Daten von der Alten Datenbank in die Neue Datenbank überführen.

(Bitte vorher immer Backups der alten Datenbank machen)

Wie funktioniert eine Access Datenbank:
- Für die Vielzahl an Daten gibt es ein Inhaltverzeichnis in der AccessDatenbank.

Das "Suchindex Aktualisieren" legt offensichtlich einzusätzliches EPLAN Inhaltsverzeichnis nur für den einen User an.

Mich würde wirklich interessieren wie groß diese Datenbank ist.
Z.B: Wieviele Artikel dort drin sind?

Viele Grüße
px

Hier noch einige Tipps und Hintergründe zum Thema Access und Performance:

http://www.dbwiki.net/wiki/Access_Performance-Tipps[/URL]
https://team-moeller.de/?Tipps_und_Tricks:Verbesserung_der_Performance

------------------
* * *  EPLAN Infoportal 2019 -->   Hilfeportal & Informationen zur EPLAN Installation (32Bit/64Bit/SQL/Helpsystem)   * * *

Viele Informationen zum Lizenzumstieg habe ich auch hier gefunden:
www.smartineer.com

[Diese Nachricht wurde von pxecad am 07. Aug. 2019 editiert.]

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

---

Hallo,

die Access Datenbank ist knapp 900mb groß mit 8190 Artikel.
Setzen viele verschiedene Hersteller ein, da ist es schwer die Datenbank klein zu halten.

Das mit dem Export und neu anlegen werde ich heute einmal machen, das lässt sich ja schnell durchführen.

Wenn das nichts bringt, werde ich mich mal drüber machen die Artikeldatenbank abzuspecken.

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

---

hallo,

900 mb bei 8000 Artikel ist viel zu groß.
bei uns ca. 5000 Artikel und 23 mb.

versuche mal dir alleine die ddatenbank zu nehmen (am besten Kopie) und mit Access zu öffnen.
da gibt es eine reparieroption oder es genügt vielleicht einfach nur im Access öffne und wieder schließen.
die größe der db sollte sich massiv reduzieren.
eplan hat das Problem, dass bei importen oder massenbearbeitung die größe extrem ansteigt.

------------------
ruplan4.70
eplan5.x
P8 V1.9 bis V2.7

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

---

Hallo Hans,

ok, dass ist auf jeden fall ein krasser Unterschied.

Da kann ich mir schon vorstellen, dass sich die Zugriffszeit deutlich verringert.

Ich hab gedacht, dass eine Datenbank von 900mb normal ist 

Muss ich mal checken ob ich die Datenmenge mit Access verringern kann.

DANKE !

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

---

Zitat:

---

Original erstellt von 3rnie:
Hallo Hans,
Ich hab gedacht, dass eine Datenbank von 900mb normal ist  
!

---

Das liegt daran, weil Access für jeden Benutzer und für jeden Zugriff an jedem Tag eine interne Historie ablegt.

D.h. je mehr Benutzer und je länger eine Datenbank verwendet wird. (Ohne Komprimierung) und Neu anlegen, desto größer wird diese.

Bei SQL passiert das nicht (in der Größenordnung).

Siehe dazu meine oberen Links, dass Access nicht für Multi User Betrieb ausgelegt ist.

Datenbank komprimieren:
https://praxistipps.chip.de/access-datenbank-komprimieren-so-gehts_41495

Datenbank per Batch/Kommandozeile komprimieren:
start /min /wait "%PROGRAMFILES(X86)%\Microsoft Office\Office16\MSACCESS.EXE" "E:\DATA\2.8.3\Parts\ESS\TEST.mdb" /compact

viel Erfolg
px

------------------
* * *  EPLAN Infoportal 2019 -->   Hilfeportal & Informationen zur EPLAN Installation (32Bit/64Bit/SQL/Helpsystem)   * * *

Viele Informationen zum Lizenzumstieg habe ich auch hier gefunden:
www.smartineer.com

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

---

Das eigentliche Problem liegt doch an der IT (wie so oft). Laut MS soll man Office nicht in 64Bit installieren wegen Kompatibilitätsprobleme zwischen 32 und 64 Bit Version. Also mach IT das und installiert 32 Bit Office. EPLAN will alles nach MS Wunsch machen (programmieren ja mit MS Visual Studio) und deshalb 64 Bit. Und da hat man schon das Problem. EPLAN ist wieder mal fern der Wirklichkeit angekommen. Ist aber auch bei Netzwerkverbindungen genauso. Also hilft nur tüfteln oder SQL. Besser wäre hier von EPLAN Seite gleich SQL mit zu integrieren im Programm.

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

---

Hallo,

wollte hiermit den Beitrag schließen.

Ich habe jetzt die Datenbank exportiert (.xml) und eine neue Datenbank angelegt und meine Artikel wieder importiert.

anstatt 900mb bin ich jetzt bei 50mb und siehe da....die Datenbank hat wieder Zugriffszeiten die ABSOLUT wieder in Ordung sind.

Keine ewigen Ladezeite mehr.

DANKE noch mal....            

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

---

Zitat:

---

Original erstellt von 3rnie:
Hallo,

wollte hiermit den Beitrag schließen.

Ich habe jetzt die Datenbank exportiert (.xml) und eine neue Datenbank angelegt und meine Artikel wieder importiert.

anstatt 900mb bin ich jetzt bei 50mb und siehe da....die Datenbank hat wieder Zugriffszeiten die ABSOLUT wieder in Ordung sind.

Keine ewigen Ladezeite mehr.

DANKE noch mal....                   

---

Guter Tipp 

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

---

Zitat:

---

Original erstellt von 3rnie:
.. Ich gehe auf Dienstprogramme\Artikel\Verwaltung\Extras --> Suchindex aktualisieren...

---

Hallo 3rnie,
hast du beim Suchindex aktualisieren auch darauf geachtet, dass kein anderer User die Datenbank geöffnet hatte?

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

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

---

Hallo,

würde das Problem gerne nochmal aufgreifen.

Habe mittlerweile alles was ich weis versucht (Datenbank komprimieren, Suchindex aktualisieren, SQL-Umstieg, ...) und komme derzeit auf folgende Performance:

SQL - Netzwerk --> 27s
SQL - Lokal --> 20s

Access - Netzwerk --> 24s
Access - Lokal --> 23s

wir haben keine große Datenbank (Access-Datei 40MB, ca. 6200 Artikel)

Bin mittlerweile ziemlich ratlos, da das Arbeiten immer mühsamer wird... hoffe es gibt irgendwelche neuen Erkenntnisse und Tipps?!

Mfg

EPLAN
Version: 2.8 HF7
Build: 12948

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

---

hallo,

hast du dir meine beitrag zu dem thema schon durchgelesen?

abhilfen sind unter anderem:
nicht jeder darf artikel anlegen/ändern.
abwahl der einstellung dass man artikel während der grafischen bearbeitung ändern darf.

wie viele anwender greifen gleichzeitig auf dir artikel-db zu?

lg
hans

------------------
ruplan4.70
eplan5.x
P8 V1.9 bis V2.7

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

---

Ja,

habe gerade eine neue Artikeldatenbank lokal erstellt. Artikel importiert, komprimiert, Suchindex aktualisiert und nochmal komprimiert.
leider keine Änderung.

Auf der Netzwerkdatenbank greifen laufend 2-4 Stationen zu.

Kann es sein, dass die Performance mit der Baumkonfiguration zusammenhängt? Hab diese mal auf Standard gestellt und siehe da, Performance top.
Nur ist es halt mühsam ohne jegliche Gruppierung zu arbeiten...

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

---

Kann mir nicht vorstellen, dass es mit der Darstellung der Baumkonfiguration zu tun hat. Außer lässt da komische Sachen anzeigen.

In meinem Fall nur:

Artikel (Trennzeichen) Artikelbezeichnung 1 (Trennzeichen)

Evtl. kannst du ja mal probieren bei der Baukonfiguration Bohrbilder/Anschlussbilder/Zubehörplatzierung auszublenden

Oder mal den Haken bei "SQL-Server Volltextsuche verwenden" setzen/nicht setzen

[Diese Nachricht wurde von 3rnie am 16. Dez. 2020 editiert.]

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

---

Ich glaube die Anzeige ist nicht das Problem, jedoch werden die Artikel im Vorfeld in mehrere Gruppen geteilt (SPS, Kabel, Schaltschrank, etc.). Von diesen Gruppen gibt es benutzerabhängig 6-8.

Ich denke das diese Gruppen das Problem sind, weil da die Artikel scheinbar genau so oft geladen werden müssen, wie es Gruppen gibt... und danach auch noch gefiltert werden.

Hab das mit den Bohrbilder usw. versucht keinen Unterschied. Auch mit der Volltextsuche ändert sich nichts.

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