---

Hallo,
wenn es heisst: 'Der Workspace muss gelöscht werden', wie geht ihr dann vor? Das komplette .proi Verzeichnis löschen?

Normalerweise sollte es doch reichen, unterhalb des .proi Verzeichnisses die Workspace-Verzeichnisse und die local.ddb zu löschen? Damit bleibt die Filestruktur einschliesslich ilprefs.txt, Bookmarks, Javafiles etc. erhalten und braucht nicht umständlich gesichert und wiederhergestellt werden.

Die PTC-Hotline (aus München!) sagt, normalerweise muss man das ganze .proi Verzeichnis löschen, partielles Löschen hätte man noch nicht probiert....

Grüsse,
Cornelia

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

---

Hallo

ich lösche immemr das gesamte proi Verzeichnis.
Das wegkopieren und zurückkopieren der pers. Einstellungen
hat bei uns noch nie funktioniert und deshalb der harte WEG.

Aber vielleicht hat jemand einen Tipp wie es besser geht?

mfg
Volker

------------------
bisschen Pfeffer???

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

---

Hallo Cornelia,

unsere Erfahrung dazu: wenn es schon soweit ist, dass es korrupte WS gibt, dann sollte das ganze .proi-Verzeichnis gelöscht werden.

Private Dateien wie ilprefs.txt, Java-Files oder Pro/E-Startbefehle können vorher gesichert und im neuen .proi-Verzeichnis wieder verwendet werden. Das funktioniert bei uns ganz gut.

Gruß Marianne

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

---

Hallo,

wenn die persönlichen Einstellungen gerettet werden sollen, dann muß man die ilprefs.txt wegspeichern. Dann kann das .proi-Verzeichnis gelöscht werden.

Dann starte ich ProI und beende ProI dann wieder.
In das nun vorhandene .proi-Verzeichnis kopiere ich die ilprefs.txt wieder rein. Unter 3.2 tut's das wie eine eins.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

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

---

Hm, danke schon einmal für eure Beiträge. So ganz überzeugt mich das komplette löschen noch nicht. Wenn der Workspace tatsächlich korrupt ist, dann ist das wohl besser, aber rein zur Vorbeugung ...?

Hat denn jemand schon negative Erfahrungen mit dem 'partiellen' löschen?

@Volker,
was genau funktioniert denn dann bei euch nicht?

Grüsse,
Cornelia

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

---

Hallo,

mal eine ganz andere Frage zu dem Ganzen:
Sind korrupte Workspace bei den neueren Versionen wieder ein Problem?
Bei der 3.1 war das ja ein Dauerthema, aber seit dem Umstieg auf 3.2 hatte ich bei 10 Arbeitsplätzen in 2 Jahren nur noch einmal ein Problem damit.

Gruß

Michael

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

---

Wir haben ca. 220 Pro/I-User.

Seit Anfang 2004 (Pro/I 3.2) bis heute (Pro/I 3.4 M011) hatte ich ungefähr 5 Fälle mit korrupten WS.

Gruß Marianne

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

---

Hallo,

ich kann mich da Bernhard Veckes und Marianne nur anschliessen.
Pro/E-Startbefehle und ilprefs.txt wegsichern und .proi komplett löschen. Hat bei uns unter 3.3 noch immer funktioniert.

@Michael
bei 3.3 auf 4 Arbeitsplätzen in 1 3/4 Jahren 6x korrupte Workspaces.
Hängt aber wohl auch von den durchgeführten Aktionen im Workspace ab.

Gruß
Gernot

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

---

Zitat:

---

... sollte es doch reichen, unterhalb des .proi Verzeichnisses die Workspace-Verzeichnisse und die local.ddb zu löschen ...

---

Für mich ist das Vorgehen von Cornelia (siehe Zitat) zur "offiziellen" Variante - nämlich .proi zu löschen und dann alles Benutzerdefinierte wieder hineinzukopieren - nahezu identisch, da sie ja nicht nur (hoffentlich alle!) Workspace-Verzeichnisse löscht, sondern auch die local.ddb.

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

Hallo,

wenn man bei einem laufendem Check Out den Pro/I-Client abschießt, dann ist der betreffende WS definitiv kaputt.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

[Diese Nachricht wurde von bernhard.veckes am 15. Jul. 2005 editiert.]

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

---

Hallo,

normalerweise ist nicht der Workspace kaputt sondern die Einträge in der Local.ddb, die im .proi-Verzeichnis liegt und die Daten aller Workspaces (Attributinformationen und Fileinformationen) besitzt. Damit hilft ein Löschen des Workspaces überhaupt nicht, sondern die lokale Datenbank ist kaputt und somit das Ganze .proi-Verzeichnis. Im Notfall kann man noch mal versuchen, die wichtigsten Daten mit proe -w:<WorkspaceName> (vorher noch set PDM_LDB_PATH auf das .proi-Verzeichnis) aufzurufen und ein Backup ins Filesystem zu machen.

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

---

Hallo,

natürlich ist die local.ddb defekt. Aber nur die Einträge, die den entsprechenden WS betreffen.

Bei dem Kopieren aus dem "WS-Verzeichnis" ist folgendes zu beachten.
Sollte in einem WS ein Teil mal von a.prt nach b.prt umbenannt worden sein. So bleibt der Dateiname im WS-Verzeichnis a.prt.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

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

---

Hallo,

ich würde auf jedem Fall das .proi - Verzeichnis komplett löschen.
Bei uns existiert eine Anweisung, dass dieses regelmässig durchgeführt wird, aus folgendem Grund:

Ab einer Größe der lokalen Datenbank (\Arbeitsverzeichnis\.proi\local.ddb) von ca. 500 MB, oder längerem arbeiten (ab 3-4 Wochen) mit der Datenbank ohne diese zu erneuern, können Abstürze oder Fehler auftreten.
Dies führt dazu, dass in keinem Workspace mehr gearbeitet werden kann und INTRALINK beim Versuch des Zugriffs auf den Workspace – Bereich abstürzt.

Die Datei ilprefs.txt wird gesichert und nach dem Neuanlegen von .proi wieder zurückkopiert.
Wir arbeiten mit IL 3.3 (2003290) / WF I (M200).
Nach dem dieses Verfahren eingeführt wurde sind keine Abstürze mehr aufgetreten.

------------------
Gruß

CADUBR

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

---

... zum reinen Kleiner-, Stabiler- und Schnellermachen der lokalen Datenbank lässt sich natürlich auch "ldbcompact.bat" aus dem "bin" Verzeichnis (sehr erfolgreich) einsetzen ...

------------------
Genius is 99 percent perspiration and 1 percent inspiration! ... Thomas Edison

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

---

Hallo,

ich lasse via Start-Script die Local.ddb einmal am Tag verkleinern.
Vorher sichere ich die Local.ddb weg (nur für den Fall, dass was daneben geht). Ich habe bei ca 60 Anwendern keine Problemen mit zu großen lokalen Datenbanken.
Den Frame-Manager habe ich auf 50 eingestellt.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

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

---

Werden die 50 Frames wirklich genutzt?

Wir haben nach der Umstellung auf 3.4 in Abstimmung mit den Konstrukteuren die Frames auf von 20 auf 5 reduziert.

Das tut nicht nur der local.ddb gut, sondern auch der lokalen Festplatte, wo die zu den einzelnen Frames gehörenden Pro/E-Files gespeichert werden.

Gruß Marianne

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

---

Hi,

mit 50 bin ich auf der sicheren Seite.
Bei Anwendern mit größeren Baugruppen reduzieren wir die Frames.

Zur Zeit haben wir mit Pro/I 3.2 keine Performance-Probleme.
Ich hoffe, dass das mit Pro/I 3.4 so bleibt.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

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

---

hi,

auch bei uns läuft beim start ein script. dies überprüft die größe der localen datenbank. wird diese größer als 40 MB, dann wird der datenbankfile gesichert und danach wird er komprimiert.

also ich bin der meinung 25 frames sollten es auf jeden fall sein. oft ist es so (wenn man oft speichert), dass schnell ein stand zurückgeholt werden soll, der schon etwas länger her ist und da sind 5 imho definitiv zu wenig!

------------------
cu
fossy
          baumrasen.de

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

---

Hallo Gemeinde!

Das was Ihr beschrieben habt zum Aufräumen des Workspace entspricht auch meinen Erfahrungen. Zwei Sachen sollte man noch bedenken:
1.) Wenn man Intralink-Macros (Scripts) verwendet, muss man diese auch wegsichern oder eben nicht löschen, verstecken sich in .proi\.. ..\lib und ..\source
2.) Die Angabe der Anzahl der max. gespeicherten Einzelbilder beschränkt nicht die Einzelbilder die durch Speichern aus Pro/E entstehen.

------------------
Gruß
Lothar

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

---

Zitat:

---

Original erstellt von bernhard.veckes:
Zur Zeit haben wir mit Pro/I 3.2 keine Performance-Probleme.
Ich hoffe, dass das mit Pro/I 3.4 so bleibt.

---

Was die Performance von Intralink 3.4 betrifft, so gibt's hier dazu ein paar sehr gute Hinweise:
http://ww3.cad.de/foren/ubb/Forum69/HTML/000618.shtml

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

---

Hallo JPietsch,

danke für den Hinweis.

Meine gesammelte Info ist bis jetzt:

- der Client soll klar schneller sein (als 3.2)
- die Suche ist langsamer, da bedarf des des beschriebenen Tunings.

------------------
Mit freundlichen Grüßen

Bernhard Veckes

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

---

Wir testen gerade 3.3 2003290 gegen 3.4 M010. Leider sind die Einflüsse unseres (wie üblich viel zu langsamen Netzwerkes) so dominant (und schwanken auf Grund unterschiedlicher Auslastung auch permanent), daß ich noch keine einheitliche Aussage zu den Performance-Unterschieden treffen kann.

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