| |
| SOLIDWORKS Grundlagen Schulung, ein Seminar am 13.01.2025
|
Autor
|
Thema: Missglückter Migrationsversuch von DBWorks auf PDMWorks (4711 mal gelesen)
|
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 07. Dez. 2008 09:04 <-- editieren / zitieren --> Unities abgeben:
Da unsere SWX2008 DBWorks Umgebung zunehmend mit nicht mehr akzeptablen Antwortzeiten sehr unangenehm auffällt, haben wir einem Dienstleister die Migration zu PDMworks in Auftrag gegeben. (Das Filesystem der Datenbank enthält 50.000 bis 100.000 Dateien. Es wird ein 1-Gigabit-Netzwerk eingesetzt.) Leider gestaltet sich das Unterfangen nun sehr unbefriedigend. So wurden bei einer Massenänderung im DBWorks Datenbestand sehr viele Zeichnungen zerstört. Ein Fehler resultiert daraus, dass Zeichnungsrahmen vertauscht wurden. Ein anderer Fehler verursacht deutlichen Geometrieverlust in Zeichnungen. Die Bemaßungen sind also noch vorhanden, zugehörige Geometrie wird nicht mehr angezeigt. Hier sind eine geringere aber völlig unbekannte Anzahl Zeichnungen betroffen. Ob weitere Fehler vorhanden sind, kann heute nicht sicher gesagt werden. Da die oben erwähnte Massenänderung eigenartigerweise ohne ausreichende Tests an Produktivdaten und nicht in einer sehr einfach einzurichtenden, parallelen Testdatenbank (auf dem gleichen Server) durchgeführt wurde, mussten wir auf ein etwa 2 Wochen altes Backup zurückgreifen. Es gibt bei uns tägliche Backups. Das erste augenscheinlich Fehlerfreie war nun leider so alt. Die in den etwa zwei Wochen geleistete Arbeit muss manuell wieder ins System eingepflegt werden -> sehr ärgerlich. Die Fragen sind nun: - Hat jemand ähnliche Erfahrungen gemacht? Wie sieht die Lösung insbesondere des zweiten Fehlers aus? (Der erste Fehler kann sicher vermieden werden. Die Ursache des Zweiten ist uns völlig unklar.) - Lässt sich DBWorks irgendwie um den Faktor > 20 beschleunigen? Das wäre für vernünftiges Arbeiten bei > 100.000 Dateien im DBWorks Filesystem tatsächlich notwendig. Gibt es dazu "Standardtipps"? Dann würden wir den Migrationsversuch evtl. abbrechen. Vielen Dank für Hinweise! ------------------ Gruß SWX-Nutzer [Diese Nachricht wurde von SWX-Nutzer am 08. Dez. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Oberli Mike Ehrenmitglied V.I.P. h.c. Dipl. Maschinen Ing. / Supporter
Beiträge: 3873 Registriert: 29.09.2004 SolidWorks 2009 (SP5) HP XW 8600 Intel Xeron (3GHz) 3 GB RAM Nvidia FX 1700 Windows XP SP3
|
erstellt am: 08. Dez. 2008 07:24 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Zitat: Original erstellt von SWX-Nutzer: mussten wir auf ein etwa 2 Wochen altes Backup zurückgreifen.
Da müsst ihr euch selber an der Nase nehmen. Bevor mein einen solchen Migrationsversuch startet, stellt man sicher, dass ein sauberes Backup vorhanden ist. Vor der effektiven Migration kontrolliert man das Backup auch. Hat euch das der Dienstleister nicht gesagt? Zitat: Original erstellt von SWX-Nutzer: So wurden bei einer Massenänderung im DBWorks Datenbestand sehr viele Zeichnungen zerstört.
Ich dachte jetzt ihr wollt von DBWorks nach PDM-Works Enterprise migrieren, wieso dann eine Massenänderung im DBWorks Datenbestand? Zitat: Original erstellt von SWX-Nutzer: - Lässt sich DBWorks irgendwie um den Faktor > 20 beschleunigen? Das wäre für vernünftiges Arbeiten bei > 100.000 Dateien im DBWorks Filesystem tatsächlich notwendig.
Kenne DBWorks nicht. - Ist die Netzwerkanbindung von Datenbank und Fileserver sauber? - Hat der Datenbankserver genügend RAM (Nachfragen beim Reseller wie viel notwendig ist) Gruss Mike
------------------ The Power Of Dreams Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
acidt Mitglied Konstruktion / Entwicklung / CAD / PDM
Beiträge: 126 Registriert: 15.08.2006
|
erstellt am: 08. Dez. 2008 07:33 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
@SWX -Nutzer Hallo, also wir befinden uns gerade auch im Umstieg von DBworks auf SW Enterprise PDM. Aber mann muss sagen wir haben immer alles nur mit einer Sicherung gemacht! Alles andere wäre auch grob Fahrlässig gewesen!!! Wir haben dabei auch schon mißerfolge & Rückschläge gehabt! Aber der letze Import auf die Testdatenbank sah sehr gut aus! Ich werde das ganze noch diese und nächste Woche testen und dann werden wir Ende der 51 KW den richtigen Import ( nach vorheriger Sicherung ) durchführen! Bin da recht optimistisch! Man muss aber immer bedenken das bei Importen oder ähnlichem nie alles glatt laufen wird. Deshalb sollte man auch immer mit Sicherungen arbeiten! Und genügend Zeit für so ein Unterfangen einplanen!!! Gruss acidt ------------------ Moinsen !!! [Diese Nachricht wurde von acidt am 08. Dez. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dopplerm Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 3636 Registriert: 11.02.2005 Win 10 64bit SWX 2019 SP 5.0
|
erstellt am: 08. Dez. 2008 13:18 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
wechselt ihr auf pdmworks, oder enterprise? pdmworks, war keine richtige datenbank, erst die enterprise ist eine lg martin ------------------ Bin jetzt auch unter Skype erreichbar , einfach nach Martin Doppler in Wien suchen. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 08. Dez. 2008 19:30 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Oberli Mike: ...
Das ist alles eigenständig von unserem Dienstleister gemacht worden. Wir haben hier selbsttätig keinerlei Aktionen durchgeführt. Die Nase, die man anfassen muss, ist also nicht unsere. Wie ich oben geschrieben habe, sind tägliche, vollständige Backups vorhanden. Das Problem ist dadurch entstanden, dass vom Dienstleister eine fehlerhafte Massenänderung ohne ausreichende Tests in den Produktivdaten durchgeführt wurde. Die Fehler "wachsen" dann in die täglichen Backups, bis man merkt, dass da etwas nicht stimmt. Massenänderungen im DBWorks Datenbestand sind zur Vorbereitung der eigentlichen Migration nach Ansicht unseres Dienstleisters erforderlich. Das wird so auch stimmen. Zur "eventuellen" Behebung der DBWorks Antwortzeitprobleme wurde vom Dienstleister ein "Projekt" empfohlen. Es geht nicht um so schlichte Dinge wie Netzwerkanbindung oder RAM. Da kann wohl nur jemand Tipps geben, der DBWorks und diese Probleme genauer kennt. Ich vermute, dass die 50k bis 100k Dateien im Datenbankpfad DBWorks über den Kopf wachsen. In diesem Fall könnte eine Bereinigung von nicht mehr benötigten Dateiversionen die Situation über einen gewissen Zeitraum erleichtern. Wir suchen aber eine dauerhafte Lösung. Zitat: Original erstellt von acidt: Aber mann muss sagen wir haben immer alles nur mit einer Sicherung gemacht! Alles andere wäre auch grob Fahrlässig gewesen!!! ... Und genügend Zeit für so ein Unterfangen einplanen!!!
Ich denke, hier ist mit "Sicherung" ein paralleles Testsystem gemeint. Ich sehe den Ablauf unseres Dienstleisters auch als (grob) fahrlässig an. Allen unseren Dienstleistern wurden in den letzten 10 bis 15 Jahren in Abstimmung bei kritischen Änderungen an beliebigen Massendaten bei uns im Haus parallel laufende Testsysteme zur Verfügung gestellt. In diesem Fall wurde dies nicht nachgefragt. (Gewünscht wurde eine Auslagerung unseres gesamten Datenbestandes zum Dienstleister. Dies ist bei uns aber aus grundsätzlichen Erwägungen nicht möglich. Hierfür gibt es heute für solche Arbeiten auch kein Argument mehr, da ausreichende Fernwartungsmöglichkeiten zur Verfügung stehen.) Seit der Beauftragung sind bei unserem Projekt inzwischen 8 Monate vergangen... Zitat: Original erstellt von dopplerm: wechselt ihr auf pdmworks, oder enterprise?
Wir migrieren nach "PDMWorks Enterprise". Herzlichen Dank an die Absender der beiden nützlichen Private Messages! Kann noch jemand auf meine im Eingangsposting genannten Fragen antworten? ------------------ Gruß SWX-Nutzer
[Diese Nachricht wurde von SWX-Nutzer am 09. Dez. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 10. Dez. 2008 17:01 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hallo Nutzer, wir haben beide Systeme und machen da Dienstleistungen für. Umstellung noch nicht gemacht, da meist den Kunden zu teuer alles neu zu bezahlen... Wichtig halt was soll mit Umstellung erreicht werden? Geschwindigkeit? OK: Wenn Ihr das System von PDM für DBWorks nutzen wollt Also immer auf Server Daten ablegen, dann zur Bearbeitung auf den lokalen Rechner kopieren... Zur Sicherung auf dem Server(Nachtsicherung wichtig..) der Rückweg MUSS auch wieder erfolgen: immer daran denken!!! (Also Einchecken sonst Daten nur Lokal) In DBW nennt sich diese Funktion Local Check-Out Mode. Da das Laden Speichern Kopieren zu mindestens 90% von den Datengrößen, Rechnerqualli und Netzwerkleistungen abhängt, sollte somit fast exakt die gleiche Geschwindigkeit mit beiden Systemen erzielt werden. Dateianzahl 50.000 und Größer: Wo ist hier ein Zusammenhang mit Geschwindigkeit? Wieviele Daten Ihr auf dem Server als Files habt, macht doch keinen Unterschied beim Laden einer Datei? In den Tabellen des SQL Servers sind Metadaten abgelegt. Beide Systeme nutzen die selbe Software?!
Bei PDM sind die Metadaten nur in mehr Tabellen verteilt als in DBWorks. Bei SQL Suchen sind hier aber kaum Geschwindigkeitsänderungen durch die Anzahl der Tabellen gegeben? Hier sehe ich also auch keine großen Unterschiede? Thema Datenverlust: Für PDM muss mann ja die Referenzen der Modelle zu Zeichnungen ändern. Also vorher X:\cad\Teil1.sldprt zu c:\PDM_Tresor\Projektordner123\Teil1.sldprt Da muss dan sämtlicher Altdatenbestand angegangen werden. Dabei kommt es schon zu schönen Sachen aus SWX Wenn Ihr dann noch andere Rahmen nutzen wollt und die draufsetzt... Das ist glaube ich eher das Problem mit SolidWorks alles was Ihr gemacht habt wieder anzupacken als das PDM die neuen Daten auf C:\PDM_Tresor\ bekannt zu geben Zu DBWorks Filesystem:
Das gibt es nicht! Hier besteht ein grundsätzliches Verständnisproblem. Alte 2D EDM Systeme haben früher (ich mach das mit EDM schon fast 15 Jahre) Eine große MEGADATEI auf dem Serverr erstellt und alles in diese Datei eingepackt. 3D wäre das tödlich. Daher muss jedes Verwaltungstool mit Dateien arbeiten! Ob diese Dateien jetzt auf dem Server in ein Verzeichnis Vault (PDM) oder durch DBWorks in eine andere Struktur gelangen? Da ist kein Unterschied!!!! Was PDM schöner macht: Bei DBW muss mann die Verzeichnisse Verstecken (Windows) Bei PDM braucht man das nicht extra (keine Win Freigabe für die User auf die Filestruktur des Vaults) Tja... Hier habe ich jetzt Feierabend, sonst schreib ich wahrscheinlich noch bis morgen weiter. Also Dienstleister muss Wissen haben... Gruß Bernd
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
PDM-Nutzer Mitglied Ingenieur
Beiträge: 1 Registriert: 10.12.2008
|
erstellt am: 10. Dez. 2008 17:03 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
|
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 12. Dez. 2008 21:37 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von BerndB: Dateianzahl 50.000 und Größer:Wo ist hier ein Zusammenhang mit Geschwindigkeit? Wieviele Daten Ihr auf dem Server als Files habt, macht doch keinen Unterschied beim Laden einer Datei?
Dank für den ausführlichen Kommentar. Wir haben halt erlebt, dass DBWorks im Lauf der Zeit mit wachsendem Datenbestand um einen Faktor 2 bis 10 langsamer geworden ist. Manche Baugruppen lassen sich kaum oder gar nicht mehr einchecken, da der Eincheckvorgang fallweise nach 10 bis 30 Minuten abbricht. Wo dieser Zusammenhang seinen Ursprung hat, wissen wir nicht. Man kann aber aufgrund der Systemarchitektur von DBWorks vermuten, dass das möglicherweise unvermeidbar ist. Uns ist bekannt, dass man lokal schneller arbeiten kann. Dies nützt aber beim Aus- und Einchecken nichts. Folgende Aussage über DBWorks (das Dokument ist erkennbar nicht mehr auf dem letzten Stand) können wir jedenfalls überhaupt nicht nachvollziehen:
"Performances: The advantages of a system of security based on Windows NT rather than on a vault are manifest when it comes to measuring the performances of a check-in and check-out of an assembly of a certain size: DBWorks is about 5 times faster than a system based on a vault and if you often work with heavy assemblies you can gain up to half an hour of work per day, on every seat." Kennt jemand die Geschwindigkeitsunterschiede, wenn DBWorks unter Microsoft Access, MS SQLServer2005/2008 oder Oracle läuft? ------------------ Gruß SWX-Nutzer
[Diese Nachricht wurde von SWX-Nutzer am 13. Dez. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Jochen Renz Mitglied Dipl.Ing. Dipl.Wirt.-Ing.
Beiträge: 127 Registriert: 25.10.2001 keytech GmbH Süd
|
erstellt am: 16. Dez. 2008 10:50 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hallo Zusammen, PDM Systeme generell, nicht nur DBWorks, werden im Allgemeinen durch zwei Faktoren ausgebremst: 1. Im Filesystem, das die Dateien enthält, liegen zu viele Dateien in einem Verzeichnis. Das kann leicht geprüft werden. 2. Die Datenbank. Oft ist es so, dass PDM mit kleinen Datenmengen und z.B. MS Access als Datenbank gestartet wird. Wenn die Datenmengen steigen, dann kann oftmals die Performance nur durch den Wechsel auf andere Datenbanken, zum Beispiel MS SQL Server, wieder erreicht werden. Das wären so meine ersten Ansatzpunkte, um die DBWorks vielleicht wieder ans Rennen zu bringen. Viele Grüße aus dem Süden Jochen Renz ------------------ Jochen Renz, MaxxSoft GmbH, Benzstrasse 15, 89129 Langenau, Tel: 07345 9617 0, Fax: 07345 9617 99, E-Mail: renz@maxxsoft.de , Web: www.maxxsoft.de Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Redfox11 Mitglied PDM Vertriebsleiter Central Europe
Beiträge: 1 Registriert: 16.12.2008
|
erstellt am: 16. Dez. 2008 14:12 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hallo, ich finde das hier ist ein sehr interessante Anfrage bezüglich eines performance Vergleichs. Bei allen PDM Lösungen (auch bei unsere freundlich Mitbewerber wie zum Beispiel Siemens, etc :-)) wird immer diese Frage "was ist schneller" gestellt. Hersteller/Vertriebspartner sagen immer, Sie seien schneller aber ein eigener Test könne diese Aussage am besten unterstützen oder vernichten. Bei einem Performance Test sollten die gleichen Voraussetzungen vorhanden sein: 1) Hardware und Netzwerk sollten gleich sein 2) Datenmenge und -grösse sollte gleich sein 3) Software auf neueste Stand bringen (Alle Windows Patches, SWX Patches, etc) 4) Test Scenario soll deutlich mit Zielen dokumentiert sein. 5) Bitte kein Demonstration des Vertriebspartners ausführen lassen. Die technische Infrastruktur ist bei viele Lösungen unterschiedlich. Bei SWX Enterprise PDM und DBworks ist auch die Grundlage der Technik ziemlich unterschiedlich. Aber die Diskussion über eine bessere Technologie ist eigentlich aus meiner Sicht irrelevant, da eigene Tests die Antworten geben ob es schneller ist oder nicht. Zum Verbessern von Performance stehen bei PDM dann noch verschiedene Möglichkeiten offen wie… - Microsoft SQL Tuning - Netzwerk Verbesserungen (Wie zum Beispiel bei verteilten Standorte Netzwerk Booster mit gezielte Port Preferenz) - Hardware Verbesserungen (Wie zum Beispiel schnellere Harddisks) …zur verfügung. Aber... Ein Entscheidung Richtung SWX Enterprise PDM zu gehen hat oft nicht nur mit Performance zu tun. Da geht es auch um andere Aspekten wie: - Sicherheit - SolidWorks ist "etwas" grösser wie Mechworks, und investiert ein "bisschen" mehr in PDM im Vergleich zum gesamten Mechworks's Umsatz. - Funktion - Bei Releasewechsel ist Enterprise immer schneller mit die Unterstützung der neue CAD Funktionen wie zum Beispiel in 2009 die funktion "Speedpack". - Funktion - Alle Funktionen in einer Software Lizenz (zum Beispiel: alle CAD Interfaces) - Support - Die gesamte SWX Support Mannschafft steht dahinter. Das sind einige Leute mehr als bei den Kollegen der Partner Produkte vorhanden sind. - Zukunft - Investition von SolidWorks gehen sicherlich nicht in Verbesserung der Anbindungen von Partner Lösungen. SolidWorks wird einiges mehr an Investitionen direkt in Enterprise PDM stecken. Wichtig sollte auch sein: Aussagen von DBWorks Fans sind immer sehr kritisch für andere Lösungen. Ein "Neu" kauf von SWX Enterprise PDM setzt voraus, das Sie einige der obenstehende "Benefits" und evtl noch andere als sehr vorteilhaft sehen. Nur dann sollte diese Umstieg stattfinden. Da Software meistens nach einige Zeit abgeschrieben ist, und der Nutzen von, in diesen Fällen von DBWorks, bereits durch die Jahre erreicht sein sollte, handelt sich es hier um ein Investion in die Zukunft in Richtung eines von Dassault SolidWorks entwickelten Produktes. Ob Sie da umsteigen oder nicht ist immerhin ein eigene Entscheidung und nicht von SolidWorks erzwungen. Es ist aber doch hoffentlich klar das SolidWorks in Enterprise PDM Partner und sein Produkt investiert um dieses Produkt am Markt weiter zu etablieren. Fragen Sie einfach mal ein SolidWorks Mitarbeiter welches System aus Sicht des Hersteller strategischer ist. Dieses Jahr sind ja über 3500 SWX PDM Enterprise Anwender bei Neukunden und existierende SolidWorks Kunden in deutschen Raum dazu gekommen. Klar, ein Anti- SolidWorks Enterprise PDM Mensch würde jetzt wieder sagen: Klar will SolidWorks diese Aufträge für sein eigenes Produkt sehen. Ich bin so ein SolidWorks Mensch und kann Ihnen versichern, dass auch wir langfristig im Sinne des Kunde denken. Enterprise wird über die nächste Jahren eigentlich immer wichtiger, und wird auch funktional wie SolidWorks CAD extrem weiter wachsen. Ich freue mich auf ein interessante Zukunft mit euch. Entschuldigt mein niederländisch deutsch…, ist aber hoffentlich besser als unser Fussballspiel bei der letzten WM ( Mfg, Jeroen
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 16. Dez. 2008 14:55 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Jochen Renz: 1. ... 2. ...
Zu 1.: In unseren oben erwähnten Benchmarks hatte die beteiligten DBWorks Verzeichnispfade bis maximal je etwa 200 Dateien. Das sollte nicht viel sein. Zu 2.: Wir setzen den MS SQL Server 2005 ein. Zitat: Original erstellt von Redfox11: ...
Die Argumente pro PDMWorks Enterprise sind hier sicher überwiegend bekannt. Leider hilft auch umfangreiche Werbung bei den angesprochenen Problemen nicht weiter. ------------------ Gruß SWX-Nutzer
[Diese Nachricht wurde von SWX-Nutzer am 16. Dez. 2008 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
i.bot Mitglied
Beiträge: 6 Registriert: 23.10.2008
|
erstellt am: 04. Mrz. 2009 14:27 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
|
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 05. Mrz. 2009 18:56 <-- editieren / zitieren --> Unities abgeben:
- Die Migration wurde auf Grund verstrichener Fristen abgebrochen. - Die sehr großen Antwortzeitprobleme von DBWorks beim Einchecken von komplexen Baugruppen (mit externen geometrischen Referenzen) werden durch Einrichten eines von jedem Nutzer über UltraVNC erreichbaren "Eincheck-PC" gelöst. Das vermeidet dann die langen Blockierzeiten der persönlichen Workstations. - D. h.: Wir bleiben bei DBWorks. Dieses wird auf die aktuellen sonstigen Bedürfnisse hin angepasst. ------------------ Gruß SWX-Nutzer Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 20. Mrz. 2009 16:59 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Wenn Ihr bleibt, Ich würde folgendes machen: SQL Server neue Datenbank anlegen DBWorks 2 Auf einem Rechner diese Verbinden. DBWorks als Sicherung in DBWorks 2 anlegen Alle Einträge der Dok Tagelle löschen Den Testrechner OPTIONEN LOKALES ARBEITEN einrichten Dann eine vorhandene Große BG auf dem Server mit Pack and go kopieren und in DBW eintragen lassen. JETZT MAL LOKAL EIN-AUSCHECKEN lassn.... Evtl schneller lokal... PS: Bei anderen Firmen folgendes gemacht: USER SCHREIBT JOB Ein anderer Rechner checkt ein aus freigabe... Gruß
Bernd
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 01. Apr. 2009 13:42 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von BerndB: Bei anderen Firmen folgendes gemacht:USER SCHREIBT JOB Ein anderer Rechner checkt ein aus freigabe...
Vielen Dank für die Hinweise! Zum letzten Vorschlag: Kann man die dabei fallweise auftretenden Meldungen sinnvoll automatisch abfangen bzw. beantworten? Hier sehe ich bei bestimmten Fehlermeldungen ein gewisses Risiko. ------------------ Gruß SWX-Nutzer Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 22. Apr. 2009 16:34 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hallo SW Nutzer, leider erst jetzt deine Frage an mich gesehen... Klar, Meldungen sollen natürlich nicht kommen. Wenn auf dem Job-Rechner aber eine Lizenz vorhanden ist, dürften eigentlich nur die Meldungen kommen (also wenn überhaupt) die du auch beim händischen Einchecken evtl. bekommst. Sollte eigentlich alles OK sein. Ich sehe eher immer das Proble: Reihenfolge der Jobs Was wenn in der Zwischenzeit jemand die Datei wieder auscheckt, öffnet.
P.S. Was passiert beim EInchecken: - Sicherungsdatei zum rückgängig Auschecken wird gelöscht - Dateien werden je nach Option geöffnet und Aktualisiert BRUAL könnte man sogar einfach mit folgendem alles sofort eingecheckt bekommen:
Angewählter Eintrag + alle Abhängigen Nummern (WalkTree Befehl) als Makro Zusammensuchen und mit UPDATE DOKUMENT SET ZUSTAND = 'EINGECHECKT' Alles abkürzen. Dauer 2-3 Sekunden... Dann halt keine Aktualisierung... Die Sicherungen bleiben dann hat auf dem Server.. Ja, Ja viele Wege... Gruß Bernd PPS So Brutal haben wir es früher immer gemacht, wenn ein User nicht im Haus war und dennoch an den Daten geändert werden sollte. Hat eigentlich, solange man nich im LOKALEM AUSSCHEN arbeitet, broblemlos funktioniert. [Diese Nachricht wurde von BerndB am 22. Apr. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
acidt Mitglied Konstruktion / Entwicklung / CAD / PDM
Beiträge: 126 Registriert: 15.08.2006 SolidEdge ST9 DELL Precision 3620 Intel Xeon E3-1270 3,6GHz QuadroM4000 32GB RAM Win 7 64bit.
|
erstellt am: 11. Mai. 2009 08:10 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
|
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 22. Jun. 2009 12:09 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von acidt: ...
Wir sind mit der DBWorks Optimierung jetzt auch komplett fertig. Abstürze beim Ein- und Auschecken sowie Freigeben hat es danach bisher gar nicht mehr gegeben. Wenn ich die Datenbankanforderungen mal wie folgt wichte - 47 % Laden - 24 % Speichern - 12 % Auschecken und Laden - 12 % Einchecken, fallweise auf Admin-PC - 5 % Freigeben, fallweise auf Admin-PC sind wir in der Summe nun etwa 30 % schneller als vorher. Wobei die Möglichkeit besteht, eher selten auftretende, langwierige Vorgänge auf einem dafür eingerichteten Admin-PC durchzuführen. Nach Ansicht der Tabelle http://ww3.cad.de/foren/ubb/uploads/acidt/TabelleZeitvergleichdbworksPDMEnterprise.pdf , in der alle Vorgänge 1:1 gewichtet und auf den individuellen Arbeitsplatz bezogen sind, bin ich schon froh, dass wir bei DBWorks geblieben sind. PDMWorks Enterprise hätte möglicherweise keinen bzw. keinen wirklich ausschlaggebenden Zeitvorteil gebracht. ------------------ Gruß SWX-Nutzer
[Diese Nachricht wurde von SWX-Nutzer am 22. Jun. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 22. Jun. 2009 14:55 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hallo SW Nutzer, Gut zu wissen. Der Link als PDf ist schon sehr interessant.
Auschecken BG 6 sek... Muss ja wohl auch alle Dokumente zur BG auf meinen Rechner mitschaufeln. Sonst liegt ja eine leere Baugruppe ohne Teile auf meiner lokalen Platte. Wenn ich bei mir im Explorer das ohne Verwaltung mal versuche. Wieviel MB bekomme ich in 6 sek. auf meine Platte kopiert... Weiterhin machen wir gerade mit Enterprise : zusatzanwendung schreiben für: Wie Änderungsdatum oder Freigabedatum auf die Zeichnung bringen. Wird ja nicht bei der Aktion Dok geöffnet und Rahmen aktualisiert... (Dadurch Freigabe schneller..) Dadurch alle StandAlone AP bekommen Zeichnung ohne Freigabeeinträge geöffnet. Hat da jemand eine einfachere Lösung ohne Zusatzanwendung? Also: Einchecken = Rahmenupdate und Änderung eintragen Freigeben im Workflow = Rahmenupdate und Freigabefelder füllen. Frage habe ich auch schon separat gestellt.. Gruss Bernd Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 22. Jun. 2009 16:39 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Wieder Icke, Freigabefelder haben wir jetzt gefunden. Fehler liegt nur bei 2009 bei der Vorschau z.B. bei Edrw oder SWX Viewer. Dort sind die Felder leer. Wenn freigegebene Edrw geöffnet ist, stehen die Prüffelder auch im Rahemn. Habe das ganze aber jetzt noch nicht auf einem Rechner Ohne SolidWorks probiert. Sprich wenn StandAlone AP (Prüfer) Zeichnung freigibt (ohne SWX) Zeichnung dann auch OK? also funkt auch swapp.setproperty ohne SWX aber mit Enterprise.. Mal schauen.. Wenn JETZT noch einer eine Idee für die LETZTE ÄNDERUNG hat? Dann ham we nen rahmen fast wie DIN.. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 23. Jun. 2009 18:01 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von BerndB: ...
Hallo BerndB, ich würde gerne helfen, verstehe die angegebenen Probleme aber leider anhand der Darstellung überhaupt nicht. ------------------ Gruß SWX-Nutzer [Diese Nachricht wurde von SWX-Nutzer am 23. Jun. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 24. Jun. 2009 13:30 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Hi User, Also im Rahmen da gibts so Felder. Ersteller OK Freigabe OK (Workflow) Aber wer hat's zuletzt gespeichert oder zumindes den Speicherzähler (Enterprise Begriff Version) erhöht also Eigecheckt also zuletzt auf den Serverr abgelegt... Die Schweitz(ß)er ? Würd halt eine Einfache Methode für einen Eintrag Geandert durch Geändert am haben.. Also nicht aller aller erster Anleger sondern momentan zuletzter... Steht ja in der Rubrik Verlauf(en) bei einem Eintrag (rechte Maus im Explorer) Liste: Ereignis Version Benutzer Datum Änderung Eingecheckt 1001 ICH 12.12.2012 Jau 12.12.2012 und ICH gehören in den Rahmen unter den Standardfeldern (Standard laut DIN) Bearbeitet durch... Bearbeitet am.... Zusatzanwendung programmieren? RRRR.. Sorry rr habe halt schon spasss alleine mal die Änderungstexte... bei einer Freigabe per Programm sau(b)er in die Zeichnung zu bekommen. TIP SWX für die letzen 8 Änderungen 8x4 Felder anlegen und dann Über skip... füllen lassen. Dann kein Programm. Aber was wenn...(Gibt da auch so komische ausnahmen..)
[Diese Nachricht wurde von BerndB am 24. Jun. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
SWX-Nutzer Mitglied Dipl-Ing.
Beiträge: 12 Registriert: 07.12.2008
|
erstellt am: 25. Jun. 2009 09:38 <-- editieren / zitieren --> Unities abgeben:
Hallo BerndB, wir vermuten dass sich die angegebenen Probleme auf eine PDMWorks Enterprise Umgebung beziehen. Dazu sind wir nicht der richtige Anprechpartner. Wie oben gesagt, hatten wir versucht von PDMWorks nach PDMWorks Enterprise zu migrieren. Das Projekt ist aber gecrasht. Mit der optimierten PDMWorks Landschaft sind wir nun sehr zufrieden. ------------------ Gruß SWX-Nutzer Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
BerndB Mitglied Ingenieur
Beiträge: 616 Registriert: 28.09.2001
|
erstellt am: 26. Jun. 2009 08:32 <-- editieren / zitieren --> Unities abgeben: Nur für SWX-Nutzer
Holla SWX ler, OK. Danke dennoch. P.S. Um DBWorks foltter bei Freigabe zu machen, haben wir gerade analog zum Vorgehen mit Enterprise folgendes gemacht: - Zeichnungen bei Freigabe nicht öffnen (aktualisieren) Ist OK, es müssen dann aber in den Rahmen keine Berechnungen über Scripte etwas machen. Sprich: - Freigabe durch Freigabe Datum - Änderungsvermerke (Also Version, Änderungsgrund, Name, Datum) nicht Berechnen sondern als Dateieigenschaft verbinden. (Fleißarbeit Bei 8 Zeilen 8x4 SWX Verknüpfungen zu den Eigenschaften) Die Eigenschaftsnamen bekommt mann durch DBWorks Option: Unter Version: Versionsfelder in Eigenschaften schreiben.. Nur wenn mann Felder direkt mit den Dateieigenschaften verbindet, braucht man die Zeichnung nicht zu öffnen, um die Werte korrekt in die Zeichnung zu bekommen. Also: Wenn Edrw, Viewer oder SWX Zeichnung öffnet stehen die Werte im Rahmen, obwohl bei Änderung der Werte in der Verwaltung (egal Welcher) Dokument nicht anschließend geöffnet wurde. Weiere Infos müssen wir wohl mal in anderen Themenbereich oder eigenen Eintrag machen... Gruß Bernd Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |