E_PDM: When to "Add to File Vault"?

Hello

I am faced with a problem that arises from time to time, but I don't know the explanation, maybe you will have it!

When I create an assembly in Solidworks and save it to my vault (green folders, connected vault), the assembly does not always save to the vault but to the local cache. I then have to "Add the file to the safe".

Before adding the file to the trunk, I do a plan. When I save the drawing, it's in the trunk and not just in cache.

However, I do not know how to reproduce this case.

Do you have any idea what to do to get each record to the vault and not just a local file?

Cdt   

1 Like

Hello

I also face this from time to time, if someone knows how to solve this problem, I'm all for it.

Thank you

Rémi

1 Like

I'm willing to find the solution if you find it:D

It's totally random and it does it just as much on the assemblies, plans and parts as far as I'm concerned.

On the other hand, it has become quite rare since we switched to SW2016.

1 Like

Hello, we are also experiencing this problem (SW2013 + EPDM2015).

The answer I was given is that it is impossible to solve a computer problem if you do not know how to repeat it. It seems that the random computer problem does not exist.

However, the problem is not important since it can be solved manually by "Adding to the safe".

Rather frustrating.

If anyone finds the how and why I'm not a taker too.

I am subscribing to let you know if we find a solution.

Guillaume

Wouldn't it be a trunk configuration somewhere? Because personally I don't think I've ever had this bug. (SW2016).

I already had the fact that I didn't have the rights, but in this case it didn't even work by doing "Add file to safe".

 

Otherwise, when this happens to you, go to the "SOLIDWORKS PDM Administration" program, and under "Log File" and see if there is an error that may correspond to the first record of the file.

@KVuilleumier: I've already had the case also on the 2009 and 2014 versions. Very random but I am leaning towards a micro network loss at the time of recording which would disrupt the operation of the safe. We just migrated to 2016, let's see if it lasts.

No rights problems, I'm an admin of the tool so profile with extended rights on the safe.

1 Like

I don't think it's related to rights; The problem happened to me when I was an administrator, but also a "standard" user.

However, I didn't have the reflex to go and see the log file.

As soon as the problem comes back, I get the log back to see. I also lean towards network micro-loss; it seems to happen to us occasionally.

3 Likes

Hello, today I am the one who is facing this problem and several times in a row. I looked at the trunk log, no error is logged... I have no idea where this can come from either but it's very painful.

 

Have a nice day

G.

Hi all

Ialso encounter this problem randomly since I have been using E-PDM (5 years).

I have the impression that the non-addition of the file to the vault is related to the load on the server at the time of file creation. All you have to do is that the server is busy when you save the file the first time, and the file goes by the wayside.

After that, it's just my personal analysis.

Stone.

1 Like

I'm not too confronted with this problem at the moment,

On the other hand, for this problem, or others similar (macro execution problem not performed),

 

I strongly suspect the local pc, because the "add safe" task or others, are pure macro it seems to me,

which runs on the local PC, so it is enough that the PC is doing a lot of things at the same time, for it to work not well,

So you have to think about waiting and doing nothing, so that the macro runs well,

even the fact of doing F5 can be a problem I think...

Similarly, if Windows is saturated, and therefore a restart seems to do it good.

I'd be surprised if it came from an overloaded PC; at least not mine, because it never happened when I was asking the PC to make an effort (which has enough RMA proco ...).

On the other hand, following a problem with the server log file, it would be interesting to consult it as soon as the problem arises to see if the server itself does not record the problem, since the log of the client machine does not record anything.