E_PDM: Wanneer "Toevoegen aan bestandskluis"?

Hallo

Ik word geconfronteerd met een probleem dat zich van tijd tot tijd voordoet, maar ik weet de verklaring niet, misschien heb je het!

Wanneer ik een assembly maak in Solidworks en deze opsla in mijn kluis (groene mappen, verbonden kluis), wordt de assembly niet altijd opgeslagen in de kluis maar in de lokale cache. Ik moet dan "Voeg het bestand toe aan de kluis".

Voordat ik het bestand aan de trunk toevoeg, maak ik een plan. Als ik de tekening opsla, zit hij in de kofferbak en niet alleen in de cache.

Ik weet echter niet hoe ik dit geval moet reproduceren.

Heeft u enig idee wat u moet doen om elk record in de kluis te krijgen en niet alleen een lokaal bestand?

Cdt   

1 like

Hallo

Ik heb hier ook wel eens mee te maken, als iemand dit probleem weet op te lossen, ben ik er helemaal voor.

Bedankt

Rémi

1 like

Ik ben bereid om de oplossing te vinden als je die vindt:D

Het is totaal willekeurig en het doet het wat mij betreft net zo goed op de assemblages, plannen en onderdelen.

Aan de andere kant is het vrij zeldzaam geworden sinds we zijn overgestapt op SW2016.

1 like

Hallo, we ervaren dit probleem ook (SW2013 + EPDM2015).

Het antwoord dat ik kreeg is dat het onmogelijk is om een computerprobleem op te lossen als je niet weet hoe je het moet herhalen. Het lijkt erop dat het willekeurige computerprobleem niet bestaat.

Het probleem is echter niet belangrijk, omdat het handmatig kan worden opgelost door "Toevoegen aan de kluis".

Nogal frustrerend.

Als iemand het hoe en waarom vindt, ben ik ook geen nemer.

Ik schrijf me in om je te laten weten of we een oplossing vinden.

Guillaume

Zou het niet ergens een trunk-configuratie zijn? Want persoonlijk denk ik niet dat ik deze bug ooit heb gehad. (SW2016).

Ik had al het feit dat ik de rechten niet had, maar in dit geval werkte het niet eens door "Bestand toevoegen aan kluis" te doen.

 

Anders, wanneer dit u overkomt, gaat u naar het programma "SOLIDWORKS PDM Administration" en onder "Log File" en kijkt u of er een fout is die mogelijk overeenkomt met het eerste record van het bestand.

@KVuilleumier: Ik heb de zaak ook al gehad op de versies van 2009 en 2014. Heel willekeurig, maar ik neig naar een micronetwerkverlies op het moment van opname dat de werking van de kluis zou verstoren. We zijn net gemigreerd naar 2016, laten we eens kijken of het blijft duren.

Geen rechtenproblemen, ik ben een beheerder van de tool, dus profiel met uitgebreide rechten op de kluis.

1 like

Ik denk niet dat het met rechten te maken heeft; Het probleem overkwam mij toen ik een beheerder was, maar ook een "standaard" gebruiker.

Ik had echter niet de reflex om het logbestand te gaan bekijken.

Zodra het probleem terugkomt, krijg ik het logboek weer te zien. Ik neig ook naar microverlies van netwerken; Het lijkt ons af en toe te overkomen.

3 likes

Hallo, vandaag ben ik degene die met dit probleem wordt geconfronteerd en meerdere keren achter elkaar. Ik heb naar het logboek van de stam gekeken, er wordt geen fout geregistreerd... Ik heb ook geen idee waar dit vandaan kan komen, maar het is erg pijnlijk.

 

Fijne dag

G.

Hoi allemaal

Ikkom dit probleem ook willekeurig tegen sinds ik E-PDM gebruik (5 jaar).

Ik heb de indruk dat het niet toevoegen van het bestand aan de kluis verband houdt met de belasting van de server op het moment van het maken van het bestand. Het enige dat u hoeft te doen, is dat de server bezet is wanneer u het bestand de eerste keer opslaat, en het bestand buiten de boot valt .

Daarna is het gewoon mijn persoonlijke analyse.

Steen.

1 like

Ik word op dit moment niet al te veel met dit probleem geconfronteerd,

Aan de andere kant, voor dit probleem, of andere soortgelijke problemen (macro-uitvoeringsprobleem niet uitgevoerd),

 

Ik heb sterk het vermoeden van de lokale pc, omdat de "add safe" taak of anderen, zijn pure macro lijkt mij,

die op de lokale pc draait, dus het is voldoende dat de pc veel dingen tegelijk doet, om hem niet goed te laten werken,

Je moet dus denken aan wachten en niets doen, zodat de macro goed loopt,

zelfs het feit dat je F5 doet, kan een probleem zijn, denk ik...

Evenzo, als Windows verzadigd is, en daarom lijkt een herstart het goed te doen.

Het zou me verbazen als het van een overbelaste pc kwam; in ieder geval niet de mijne, want het is nooit gebeurd toen ik de pc vroeg om een inspanning te leveren (die genoeg RMA proco heeft ...).

Aan de andere kant zou het na een probleem met het serverlogbestand interessant zijn om het te raadplegen zodra het probleem zich voordoet om te zien of de server zelf het probleem niet registreert, aangezien het logboek van de clientmachine niets registreert.