Ik werk in een bedrijf met een vestiging in het buitenland.
Om linkproblemen te beperken, hebben we besloten om 2 SQL-databases voor EPDM te hebben: één in Frankrijk en de andere op de andere site (met kruisduplicatie van de 2 archiefdatabases, d.w.z. 4 archiefservers in totaal).
Hierdoor kunnen we blijven werken aan de gegevens op onze site in het geval van een link (of server) probleem met de andere site.
Het kan echter gebeuren dat we een onderzoek moeten doen door een (of meerdere) bestanden van de andere site te hergebruiken (minder dan 5% van de onderzoeken).
EPDM maakt het mogelijk om dit in een assemblage te doen. Aan de andere kant worden bestanden die zich niet in de kluis van de huidige assembly bevinden, beschouwd als bestanden buiten EPDM (zelfs als ze tot een andere kluis behoren): zie bijgevoegde bestanden. Als gevolg hiervan wijst hun pad in solidworks naar het pad van de weergave van de kluis zoals deze op de computer is geïnstalleerd.
Als een andere gebruiker het assembly-bestand in EPDM opent, bestaat de kans dat de bestanden die uit de externe database komen, worden verwijderd omdat ze niet kunnen worden gevonden: het pad van de kluisweergave kan op deze computer anders zijn, of omdat het bestand niet in de cache was opgeslagen op deze andere kluisweergave.
Om deze problemen te beperken had ik graag de weergave van de kluis van de buitenlandse basis op een netwerklocatie gezet (en deze zelfde locatie voor alle werkplekken willen gebruiken). Het belang is tweeledig: het bestand moet logischerwijs beschikbaar zijn op deze netwerklocatie, ongeacht de gebruiker die de assembly opent (aangezien het door de vorige gebruiker in de cache moet zijn opgeslagen), geen probleem om de weergave van de kluis te lokaliseren volgens de pc (pc's hebben niet noodzakelijkerwijs dezelfde configuratie).
Lijkt dit je relevant?
Kan het delen van een lokale weergave van de kluis met meerdere gebruikers een probleem zijn? (vooral als een gebruiker een bestand bewerkt terwijl anderen het gebruiken)
Aan de andere kant moeten lokale gebruikers mogelijk de bestanden in deze lokale weergave van de kluis wijzigen?
Als dit het geval is, heeft door deze weergave te delen alleen de eerste persoon die het bestand opent schrijftoegang. Als het bestand wordt gewijzigd terwijl het bestand op een ander station is geopend, ziet het de wijzigingen niet, tenzij het naar dat onderdeel zoekt in SolidWorks (http://help.solidworks.com/2013/french/SolidWorks/sldworks/HIDD_FILE_RELOAD_MULTIPLE.htm)
En als dat niet het geval is, kunt u de bestanden het beste alleen-lezen maken.
Gebruikers zouden deze bestanden normaal gesproken niet hoeven te bewerken/wijzigen (aangezien ze het "eigendom" zijn van de andere site). Maar we weten niet wat de toekomst voor ons in petto heeft (BE werklastprobleem op de buitenlandse site)...
Als u het "vreemde" deel in solidworks selecteert, wordt er een EPDM-venster geopend om in te loggen op de buitenlandse kluis (logisch aangezien deze is opgeslagen in de buitenlandse kluisweergave). U kunt op meerdere kluizen tegelijk ingelogd zijn. De weergave van het tabblad EPDM past zich aan de inhoud van het actieve venster aan en toont de kluis waar het bestand zich bevindt.
De lees-/schrijfrechten van het "vreemde" bestand worden dus beheerd door EPDM.
Normaal gesproken is dit helemaal niet de oplossing die moet worden ingevoerd.
Epdm omvat een notie van replicatie van de archiefserver, maar het verdient de voorkeur om slechts één gemeenschappelijke database te hebben. Op deze manier deelt de gebruiker in Frankrijk en in het buitenland dezelfde gegevens, een Fransman kan een bestand wijzigen zonder dat de BE in het buitenland het kan wijzigen.
De bestanden blijven dankzij de duplicatie lokaal toegankelijk, maar blijven in dezelfde kluis, zodat ze naar believen kunnen worden uitgewisseld tussen de twee sites.
Dit is het schema dat wordt aanbevolen door DS SW.
Ja, ons schema is bijzonder omdat we niet willen dat de ene site afhankelijk is van de andere voor toegang tot zijn BE-gegevens.
In het klassieke schema hebben we een "master" -site met de SQL-server op het terrein. Als de externe site geen toegang meer heeft tot de SQL-server (intern netwerkprobleem op de mastersite, internetprobleem in het land van de mastersite, internetprobleem in het land van de externe site, enz.) dan kan de BE van de externe site met zijn duimen draaien totdat het probleem is opgelost.
Omdat het ontwerpbureau van de afgelegen site substantiëler is dan dat van de mastersite, willen we ons niet in deze situatie bevinden met een geschatte 2-3 dagen / jaar blokkering (het tijdsverschil helpt ook niet).
Op dit moment t op mijn 4 archiefservers, één op de "master" -site is niet toegankelijk voor mij. Gelukkig ben ik niet in productie op deze server...
Het klassieke schema werkt goed in het geval van een hoofdontwerpbureau op een "master"-site en een klein secundair ontwerpbureau (plus methode) op een productiesite.
Zelfs als we verder gaan dan het klassieke EPDM-model, worden de vault-weergaven op dezelfde manier genoemd op de 2 sites. Heten ze bijvoorbeeld "Coffre-FRANCE" en "Coffre-ÉTRANGER", ook al verwijzen ze in feite niet naar dezelfde "fysieke" kluis?
De kluis die op een archiefserver is gemaakt en vervolgens op een andere archiefserver is gerepliceerd, heeft altijd exact dezelfde naam (dit is logisch aangezien de 2 archiefservers naar dezelfde SQL-database verwijzen). Gebruikers van de 2 sites kunnen bestanden wijzigen (als ze de rechten hebben natuurlijk). Zodra het SW-bestand op locatie A is gewijzigd, wordt het gerepliceerd naar locatie B (automatisch volgens een schema of op verzoek als er nog geen automatische replicatie heeft plaatsgevonden): dit is de basiswerking van replicatie en multisite.
Waar ik van verschil is, is dat ik aan 2 archiefdatabases tegelijk wil werken. Ik ga een assemblage van basis A hebben die een deel van basis B gebruikt. Als ik op de assembly zit (dus op basis A werk), wordt het bestand in base B beschouwd als een extern bestand voor EPDM. Als ik het bestand van database B open, dan schakelt EPDM automatisch over en werken we goed op database B. Aan de andere kant, de gebruiker die het bestand van database B niet in zijn lokale weergave heeft of dat hij het niet heeft tot de nieuwste versie, wanneer hij de assemblage van database A opent, heeft hij ofwel een verwijderd deel (omdat het niet kan worden gevonden in zijn lokale weergave) of een assemblage met een deel dat niet up-to-date is (als het bestand van zijn lokale weergave is niet op de laatste versie)
Daarom zou ik graag de lokale weergavemap op het netwerk willen hebben: om te voorkomen dat er verschillende externe links naar EPDM komen te staan van de ene gebruiker naar de andere (en met een verschillende daadwerkelijke beschikbaarheid van het bestand afhankelijk van de gebruikers: wie het bestand al dan niet lokaal beschikbaar heeft of het bestand in de laatste versie).
Mensen hebben misschien al geprobeerd om een lokale weergave op een netwerkschijf te hebben.
Dit kan interessant zijn als u de hele EPDM-database in de lokale weergave wilt hebben en met de laatste versie op alle bestanden: het is onmogelijk om dit te doen op een grote database op pc's met kleine schijven. Dit kan u ook in staat stellen om een back-up te maken van de bestanden die in de kassa zijn. Logischerwijs zouden de laadtijden langer moeten zijn, maar dit zou kunnen worden gecompenseerd door het soort voordeel dat hierboven is genoemd.
Ik zou graag feedback willen hebben van mensen die deze lokale weergave hebben geprobeerd die gemeenschappelijk is voor verschillende gebruikers en die op een netwerk is opgeslagen. Of positieve/negatieve meningen over dit idee (ik heb nog niet echt met EPDM gewerkt, dus mijn feedback is bijna nul).