Binnenkort gaan we onze database migreren van SW 2014 -> SW 2019.
Omdat ik onder EPDM val, zou ik graag willen weten wat uw praktijken / feedback zijn voor dit soort updates van alle bestanden in de database:
1) je blokkeert het werk van al je SW-gebruikers en migreert de hele database met behulp van de "SOLIDWORKS PDM File Version Upgrade Tool" met alle stations als slaves. Het duurt net zo lang als het duurt, maar als het klaar is, openen al uw gebruikers hun bestanden normaal met hun nieuwe Solidworks. De vorige keer heb ik dit gedaan en de bestanden gemigreerd, te beginnen met de .sldprt en vervolgens de .sldasm om te eindigen met de .slddrw. Maar onze database is in 5 jaar tijd opgezwollen en ik ben bang dat de conversietijd ultra lang is en dat we gebruikers enkele dagen zullen blokkeren.
2) je migreert je database 'as you go' met behulp van de "SOLIDWORKS PDM File Version Upgrade Tool": alsof je elke nacht batches van 5000 bestanden maakt om te migreren. Het is over deze optie dat ik graag feedback zou willen hebben van mensen die hun migratie op deze manier hebben beheerd. Wat gebeurt er met de manier waarop gebruikers werken als we in de overgangsfase zitten waarin de hele database nog niet is geconverteerd? Levert het knippen van de conversie 'in een puck' bijzondere problemen op? Beheer van de verschillende soorten bestanden (u volgt de volgorde .sldprt en vervolgens de .sldasm om te eindigen met de .slddrw of u doet de directory door directory migratie zonder onderscheid te maken tussen de bestandstypen)?
3) je gebruikt de "SOLIDWORKS PDM File Version Upgrade Tool" helemaal niet: daar ben ik ook in geïnteresseerd
Opmerking: Ik ben alleen van plan om de nieuwste versie van de bestanden te migreren en een speciale versie van het geconverteerde bestand te maken.
Persoonlijk is het zoals je gaat. Bestanden worden gemigreerd terwijl ze worden gebruikt.
De enige elementen die ik update zijn de bibliotheken, en dat ik op vrijdagavond met de conversie begin, en via een verbinding op afstand met mijn machine neem ik af en toe een kijkje
Edit: Ik gebruik nog steeds gegevensherstel van mycadtool om een kapotte lijst met referenties uit te voeren voor het geval dat
Bij ons identificeren we de bestanden die moeten worden geconverteerd en een opdracht om ze te converteren (zonder onderscheid tussen prt, asm en drw), te beginnen met bijvoorbeeld onze bibliotheekbestanden (schroeven, moeren, gekrompen elementen...).
Om dit te doen, gebruiken we het hulpprogramma File Version Upgrade en sluiten we de toegang tot de database af om te voorkomen dat bestanden worden uitgepakt. Bovendien, als we de trunk-weergaven verwijderen om ze opnieuw uit te voeren (geautomatiseerde installatie aangezien er een goede twintig werkstations zijn om te installeren), zou elk uitgepakt bestand verloren gaan. Dit jaar hadden we 7 conversiewerkstations beschikbaar (neem de snelste als je geen homogene pac hebt om een korte verwerkingstijd te hebben, aangezien het hulpprogramma geen onderscheid maakt tussen een grote assemblage die op een krachtige set geopend zou moeten worden en net zo goed op een "trage" set zou kunnen openen).
Om te voorkomen dat iedereen te lang wordt geblokkeerd, sluiten we over het algemeen de toegangen op vrijdag af vanaf 12 uur om ze op maandag rond 9 uur 's ochtends weer te openen (dit jaar was de omschakelingstijd korter dan in voorgaande jaren, dus we hadden de toegangen al om 7 uur 's ochtends op maandag kunnen openen).
We hebben ook een variabele geïmplementeerd om de bestanden te identificeren die de komende jaren moeten worden geconverteerd (naar schatting wordt geschat dat een bestand dat in bepaalde mappen niet beweegt, daarom niet meer wordt gebruikt en niet hoeft te worden geconverteerd).
Voor nu raad ik je wel aan om een extra versie te maken in plaats van een versievervanging. We hadden dit jaar een probleem met deze versievervangingsfunctie (dit heeft op het eerste gezicht niets met het hulpprogramma te maken, maar met deze PDM-functie).
Edit: aan de andere kant kan het nemen van een versie het volume van de archiefdatabase aanzienlijk verhogen, afhankelijk van het aantal geconverteerde bestanden.
Aan de andere kant is uw omgeving eerder een speciale machine met een directory per machine en geen gemeenschappelijke componenten behalve de schroeven?
Voor ons zijn assembly's specifiek, maar er zijn nog steeds veel onderdelen die niet in bibliotheekmappen staan, maar in tientallen assembly's worden gebruikt. Grofweg hebben we in een assemblage 5 tot 10% specifieke, 30% bouten/bibliotheekonderdelen en 60% 'gewone' onderdelen (onderdelen die worden beheerd als specifieke onderdelen, maar met veel gebruiksscenario's). Deze gemeenschappelijke stukken moeten minstens duizend stukken vertegenwoordigen en ze zijn verspreid over ongeveer 40 repertoires die elk 1000 stukken bevatten (het is een beetje een speld in een hooiberg)
Froussel, in dit geval zou ik de gemeenschappelijke bestanden en de bibliotheek bijwerken met een machine als een conversierobot die is aangesloten op een PDM-beheerder.
Thuis zijn de gemeenschappelijke elementen en de bibliotheek vergrendeld in wijziging voor gewone gebruikers, alleen de beheerder heeft het recht om deze bestanden te wijzigen, of supergebruiker, maar ze moeten door de veranderingen van de staat en rechtvaardiging voor de overgang naar wijziging gaan.
edit, ah ja ik vergat een gemeenschappelijke bestand en bibliotheek zijn in specifieke mappen, die het gemakkelijker maakt om te zoeken
Dus als u een oude assembly opnieuw opent die niet is geconverteerd, converteert u dan alle bestanden in de assembly? Of je maakt gewoon de wijzigingen die je nodig hebt en je werkt niet alle componenten bij die door de assembly worden gebruikt (dus openen met de helft van de bestanden geconverteerd en de andere helft niet geconverteerd de volgende opening)?
Als het geheel wordt gewijzigd, en dus als index wordt ingesteld, dan wordt het geconverteerd. Maar als in de batch een bestand niet omhoog gaat in de index, blijft het in de vorige versie.
Ik heb gemerkt dat dit geen probleem is, aangezien een recente versie gemakkelijk bestanden opent na SW 98
Aan de andere kant, wat ik enige tijd geleden heb gedaan, is integratie gebruiken en ervoor zorgen dat de SW-bestanden van vóór 2010 systematisch opnieuw worden opgebouwd.
Als uw database in 2014 volledig overblijft, is het geen probleem om deze te gebruiken en bij te werken als er wijzigingen worden aangebracht
In ons geval zijn er maar weinig componenten die gemeenschappelijk zijn tussen de projecten, behalve een paar componenten van schroeven in de bibliotheek.
Dus ik heb de updatetool nooit gebruikt, omdat je meestal niet meer terugkomt als het project eenmaal is voltooid, en als dit het geval is, aangezien onze assemblages niet al te groot zijn, zijn de componentupdates snel te doen (als dat nodig is).
Dus uit nieuwsgierigheid denk ik dat ik een test ga doen op de schroevenbibliotheek.
U moet weten dat de update op sommige functies/onderdelen echt essentieel is: op mijn zeer grote bibliotheekfuncties (tot 380 configuraties die verschillende groottes vertegenwoordigen) als u in 2019 probeert te bewerken, schuurt een bibliotheekfunctie die in SW 2014 bleef 5 tot 10 minuten (het converteert alle configuraties), terwijl als het bibliotheekbestand van tevoren is geconverteerd, u gewoon hoeft te wijzigen de configuratie en het duurt 5s.
Een snelle test die ik heb gedaan, laat ook zien dat een niet-geconverteerde assembly 2x langzamer opent dan de geconverteerde assembly. Aan de andere kant is het prettig dat mijn omgezette tekening sneller opent dan de originele tekening onder SW2014.