Tworzenie "widoku repozytorium" w lokalizacji sieciowej

Witam

Pracuję w firmie z oddziałem za granicą.

Aby ograniczyć problemy z łączami, zdecydowaliśmy się na posiadanie 2 baz danych SQL dla EPDM: jednej we Francji, a drugiej na drugiej stronie (z duplikacją krzyżową 2 archiwalnych baz danych, czyli w sumie 4 serwerów archiwów).

Dzięki temu możemy nadal pracować nad danymi na naszej stronie w przypadku problemów z połączeniem (lub serwerem) z inną witryną.

Może się jednak zdarzyć, że będziemy musieli przeprowadzić badanie poprzez ponowne wykorzystanie jednego (lub więcej) plików z drugiej strony (mniej niż 5% badań).

EPDM pozwala to zrobić w zespole. Z drugiej strony, pliki, które nie znajdują się w repozytorium bieżącego zespołu, są traktowane jako pliki spoza EPDM (nawet jeśli należą do innego repozytorium): patrz załączone pliki. W rezultacie, ich ścieżka w solidworks wskazuje ścieżkę widoku sejfu zainstalowanego na komputerze.

Jeśli inny użytkownik otworzy plik zespołu w EPDM, istnieje prawdopodobieństwo, że pliki pochodzące z zewnętrznej bazy danych zostaną usunięte, ponieważ nie można ich znaleźć: ścieżka widoku repozytorium może być inna na tym komputerze lub dlatego, że plik nie został zapisany w pamięci podręcznej w tym innym widoku repozytorium.

Aby ograniczyć te problemy, wolałbym umieścić widok sejfu zagranicznej bazy na lokalizacji sieciowej (i używać tej samej lokalizacji dla wszystkich stacji roboczych). Zainteresowanie jest dwojakie: plik powinien być logicznie dostępny w tej lokalizacji sieciowej niezależnie od użytkownika, który otwiera zestaw (ponieważ musiał być buforowany przez poprzedniego użytkownika), nie ma problemu ze zlokalizowaniem widoku sejfu według komputera (komputery PC niekoniecznie mają tę samą konfigurację).

Czy wydaje Ci się to istotne?

Czy udostępnianie lokalnego widoku repozytorium kilku użytkownikom może stanowić problem? (zwłaszcza jeśli użytkownik edytuje plik, podczas gdy inni go używają)

Czy są jakieś problemy, których bym się nie spodziewał?

 

Dziękuję za odpowiedzi i sugestie.

 

Witam

Wydaje się, że jest to najlepsze rozwiązanie.

Z drugiej strony, użytkownicy lokalni mogą być zmuszeni do modyfikowania plików w tym lokalnym widoku repozytorium?

Jeśli tak, udostępniając ten widok, tylko pierwsza osoba, która otworzy plik, będzie miała dostęp do zapisu. Jeżeli plik jest modyfikowany, gdy jest otwarty na innej pikiecie, nie zobaczy zmian, chyba że wyszuka tę część w SolidWorks (http://help.solidworks.com/2013/french/SolidWorks/sldworks/HIDD_FILE_RELOAD_MULTIPLE.htm)

A jeśli tak się nie stanie, najlepiej ustawić pliki tylko do odczytu.

@ .PL

Dziękujemy za zainteresowanie,

Użytkownicy zwykle nie powinni być zmuszeni do edytowania/modyfikowania tych plików (ponieważ są one "własnością" innej witryny). Nie wiemy jednak, co przyniesie nam przyszłość (problem z obciążeniem pracą na obcej stronie)...

W przypadku wybrania "obcej" części w solidworks, otworzy się okno EPDM, w którym można zalogować się do obcej przechowalni (logiczne, ponieważ jest ona przechowywana w widoku obcej przechowalni). Możesz być zalogowany do kilku sejfów w tym samym czasie. Sposób wyświetlania karty EPDM dostosowuje się do zawartości aktywnego okna i pokazuje repozytorium, w którym znajduje się plik.

Tak więc prawa do odczytu/zapisu pliku "obcego" są zarządzane przez EPDM.

 

Witam

Zazwyczaj nie jest to rozwiązanie, które w ogóle powinno być stosowane.

EPDM zawiera pojęcie replikacji serwera archiwum, ale preferowane jest posiadanie tylko jednej wspólnej bazy danych. W ten sposób użytkownik we Francji i za granicą udostępnia te same dane, Francuz może zmodyfikować plik bez możliwości jego modyfikacji przez BE za granicą.

Pliki pozostają dostępne lokalnie dzięki duplikacji, ale pozostają w tym samym skarbcu, dzięki czemu można je dowolnie wymieniać między dwiema witrynami.

Jest to schemat zalecany przez DS SW.

http://www.solidworks.fr/sw/products/product-data-management/multisite-replication.htm

@+

2 polubienia

@ Kojot

Tak, nasz schemat jest szczególny, ponieważ nie chcemy, aby jedna strona była zależna od drugiej w zakresie dostępu do swoich danych BE.

W klasycznym schemacie mamy witrynę "główną" z serwerem SQL na swoim terenie. Jeśli lokacja zdalna nie ma już dostępu do serwera SQL (problem z siecią wewnętrzną w lokacji głównej, problem z Internetem w kraju lokacji głównej, problem z Internetem w kraju lokacji zdalnej itp.), to BE lokacji zdalnej może kręcić kciukami, dopóki problem nie zostanie rozwiązany.

Ponieważ biuro projektowe witryny zdalnej jest bardziej rozbudowane niż witryna główna, nie chcemy znaleźć się w takiej sytuacji z szacowaną blokadą na 2-3 dni / rok (różnica czasu też nie pomaga).

W tej chwili na moich 4 serwerach archiwalnych, jeden znajdujący się na stronie "głównej" nie jest dla mnie dostępny. Na szczęście nie jestem w produkcji na tym serwerze...

Klasyczny schemat sprawdza się w przypadku głównego biura projektowego na stronie "głównej" i małego wtórnego biura projektowego (plus metoda) na placu produkcyjnym.

Witam

Nawet jeśli wyjdziemy poza klasyczny model EPDM, to widoki skarbca są nazwane w ten sam sposób na 2 stronach. Na przykład, czy nazywają się "Coffre-FRANCE" i "Coffre-ÉTRANGER", nawet jeśli w rzeczywistości nie wskazują na ten sam "fizyczny" sejf?

@ Benoit LF,

Magazyn utworzony na serwerze archiwum, a następnie zreplikowany na innym serwerze archiwum, zawsze ma dokładnie taką samą nazwę (jest to logiczne, ponieważ 2 serwery archiwum wskazują na tę samą bazę danych SQL). Użytkownicy 2 witryn mogą modyfikować pliki (jeśli oczywiście mają do tego uprawnienia). Po zmodyfikowaniu pliku oprogramowania w lokacji A jest on replikowany do lokacji B (automatycznie zgodnie z harmonogramem lub na żądanie, jeśli replikacja automatyczna jeszcze nie nastąpiła): jest to podstawowa operacja replikacji i multisite.

Różnica polega na tym, że chcę pracować na 2 archiwalnych bazach danych w tym samym czasie. Zamierzam mieć zespół podstawy A, który wykorzystuje część podstawy B. Kiedy jestem na złożeniu (a więc pracuję na bazie A), plik w bazie B jest traktowany jako plik zewnętrzny dla EPDM. Jeśli otworzę plik bazy danych B, to EPDM automatycznie się przełącza i dobrze pracujemy na bazie B. Z drugiej strony użytkownik, który nie ma pliku bazy danych B w swoim widoku lokalnym lub nie ma go do najnowszej wersji, otwierając zespół bazy danych A ma albo usuniętą część (ponieważ nie można jej znaleźć w jego widoku lokalnym), albo zespół z częścią, która nie jest aktualna (jeśli plik jego widoku lokalnego nie jest w najnowszej wersji)

Dlatego chciałbym mieć katalog widoku lokalnego w sieci: aby uniknąć sytuacji, w której od jednego użytkownika do drugiego będą różne linki zewnętrzne do EPDM (i że rzeczywista dostępność pliku będzie różna w zależności od użytkowników: którzy mogą, ale nie muszą mieć pliku dostępnego lokalnie lub pliku w najnowszej wersji).

Być może użytkownicy próbowali już uzyskać widok lokalny na dysku sieciowym.

Może to być interesujące, jeśli chcesz mieć całą bazę danych EPDM w widoku lokalnym i z najnowszą wersją na wszystkich plikach: nie da się tego zrobić na dużej bazie danych na komputerach z małymi dyskami. Może to również pozwolić na wykonanie kopii zapasowej plików, które są w wyewidencjonowaniu. Logicznie rzecz biorąc, czasy ładowania powinny być dłuższe, ale można to zrekompensować wspomnianą powyżej przewagą.

Chciałbym tylko uzyskać opinie od osób, które wypróbowały ten widok lokalny wspólny dla kilku użytkowników i przechowywany w sieci. Lub pozytywne/negatywne opinie na temat tego pomysłu (tak naprawdę nie pracowałem jeszcze z EPDM, więc moje opinie są prawie zerowe).

Dziękuję

 

 

Ostatecznie tego nie zrobiłem.

Zachowałem podstawowe zarządzanie z lokalnym widokiem stacji roboczych, biorąc pod uwagę niewielkie wykorzystanie amerykańskiej bazy danych