---

Hallo Forumuser,

habe folgendes Problem an allen Arbeitsplätzen allerdings nur an einem Standort. Beim anlegen eines neuen Teils egal ob über Neues Konstruktionsdokument, Konstruktionsdokument kopieren, Datenblatt kopieren, Konstruktionsdokument ersetzen durch Kopie tritt der Fehler auf, das sich das Anlagedialog von Compass nach dem Befehl speichern und schließen nicht schließt sondern offen bleibt.

Hat jemand Erfahrung mit diesem Fehler? An was könnte das liegen?

MfG
Thomas

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

---

Servus Thomas,

würde mal auf ein Problem in der Datenbank tippen. Tritt das Problem nur bei Konstruktionsdokumenten oder auch bei anderen Compass-Objekten auf? In ersterem Fall würde ich auf die DOCUMENT-Tabelle tippen.
Du schreibst "nur auf einem Standort", also gehe ich mal von einer Replikation aus. Kann es sein, dass es auch dort Probleme mit dieser Tabelle gibt?

Sieh dir mal die dbms_log im work-Verzeichnis an (am besten zuerst die Datei löschen und dann den Fehler reproduzieren).
Zusätzlich kannst schon mal, so ganz profilaktisch, im QueryAnalyzer folgenden Befehl ausführen:
DBCC CHECKDB ('CompassDB')
wobei CompassDB durch den Namen deiner Compass-Datenbank zu ersetzen ist.
Evtl. noch die Anweisung
DBCC DBREINDEX(DOCUMENT)
wobei hier erst noch die Compass-Datenbank ausgewählt werden muss.

Ciao, WolfgangE

------------------
An Optimist Is A Person Who Has Not Been Shown All The Facts Yet!!!

[Diese Nachricht wurde von WolfgangE am 07. Aug. 2007 editiert.]

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

---

Hallo Wolfgang,

ich habe das Problem an unseren Händler weitergegeben. Dies Sache ist mir ein bisschen zu heiß. Unser Händler hat festgestellt, das die Datenbanken an den einzelnen Standorten unterschiedlich sind was eigentlich nicht sein darf. Kann man die Datenbanken irgendwie vergleichen lassen um die Unterschiede zu finden?

MfG
Thomas

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

---

Servus Tom,

kommt sehr darauf an, was du unter einem Vergleich verstehst.
Wenn es dir um die Daten als solches geht, brauchst du eigentlich nur eine einfache Select-Anweisung für jede Tabelle schreiben, die die Daten aus beiden Datenbanken abfragt.
Die Schwieriegkeit besteht darin, festzulegen, ab wann die Datensätze als "gleich" gelten. Wenn AIMKEY und IDENT in beiden Tabellen dieselben sind? Oder müssen alle Felder exakt übereinstimmen? Wo liegt die Toleranz?
Es wäre auch gar kein Problem (höchstens ein klein wenig zeitintensiv) ein Skript zu schreiben, das die Inhalte aller Felder aller Tabellen vergleicht. Die Frage ist dann aber viel eher, wenn es so akribisch angehst, was mit den nicht gleichen Datensätzen anstellen willst.

Die andere Seite ist die Datenbank im Sinne ihrer Objekte, also die Frage, ob die Tabelle, Views, Procedures etc. den gleichen Aufbau haben.
Bei Views ist es relativ leicht, da sich die DDL (= Data Definition Language, sprich die SQL-Anweisung, mit der die View erstellt wurde) aus den Systemtabellen auslesen und vergleichen lässt.
Bei den Tabellen gibt es zwar keine DDL zum Auslesen, dennoch sind alle Felder mit ihren spezifischen Eigenschaften (Datentyp, Länge etc.) ebenfalls per Skript auslesbar, was einen Vergleich ermöglichen würde.
Bei den Procedures und Functions ist es im Prinzip wie mit den Views. Allerdings sind die Compass-Procedures für gewöhnlich verschlüsselt (was bei den Views übrigens auch möglich wäre), so dass den Vergleich maximal über den Objektnamen durchführen kannst.

Auf alle Fälle sollte abgeklärt werden, was dein Händler damit meint, die Datenbanken sind unterschiedlich, und worin die Ursachen liegen. Eine Datenbankreplikation kann da durchaus die Ursache sein, meist allerdings nicht aufgrund von Fehlern, sondern aufgrund falscher Einstellungen oder Objekt-Eigenschaften (v. a. Trigger können da einiges anrichten, hab da schon so meine Erfahrungen gemacht...).

Theoretisch gäbe es eine einfache Möglichkeit, den Status der Datenbank auf dem anderen Standort zu synchronisieren, indem einfach der Anfangssnapshot neu erstellt und neu angewendet wird, indem das Abonnement für die erneute Initialisierung gekennzeichnet wird.
Aber: erstens weißt dann nicht, was in der anderen Datenbank alles flöten geht, und zweitens, sollten die Ursachen tatsächlich mit der Replikation zu tun haben, ist das Problem damit bestenfalls vorübergehend gelöst.

Ciao, WolfgangE

------------------
An Optimist Is A Person Who Has Not Been Shown All The Facts Yet!!!

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

---

Hallo Wolfgang,

danke für deine Antwort. Trigger könnte möglich sein ist bei uns auch im Einsatz und hat in der Vergangenheit schon Probleme bereitet.

Ich habe den Link zu unserer Unterhaltung jetzt an unseren Händler weitergegeben, damit er diese Möglichkeit auch in Erwägung ziehen kann.

Mfg
Thomas

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

---

dann noch einen konkreteren Tipp dazu:
Wenn es tatsächlich an den Triggern liegt und an der Stelle, an der ich glaube, dann müsste der Merge-Agent der Replikation schon längst entsprechende Meldungen ausgegeben haben, bzw. müsste die hohe Anzahl an Konflikten Aufmerksamkeit erregt haben.

Trigger haben die Eigenheit, dass sie auch dann ausgelöst werden, wenn ein UPATE, INSERT oder DELETE durch die Synchronisierung bei der Replikation stattfinden. Das kann durchaus richtig sein, je nachdem was der Trigger macht, aber auch fatale Folgen haben.
Deshalb ist immer zu überlegen, ob ein Trigger mit der Option "NOT FOR REPLICATION" versehen werde sollte bzw. muss. Hatte damals eine Installation wo uns durch eine solche Kleinigkeit ein paar hundert Datensätze flöten gingen, die wir von einem Datenbank-Backup wieder importieren mussten.

Ciao, WolfgangE

------------------
An Optimist Is A Person Who Has Not Been Shown All The Facts Yet!!!

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