Long time ago I wanted to trying to added a script of Dispatch or Add-ins with a condition - if the file already exists in Vault - to insert it only as shared.
For this purpose it is possible also to try to use in PDM context menu comand of Windows - MoveTo (if such comand is absent look as to add her).
I don't remember precisely for what reason, it was necessary to postpone the solution of this question (there was some problem).
Of course, it is important to allow to copy in what states as shared.
But it seemed to me it was a problem with control of the rights for UnCheking, Changing or Deleting (the right of the Author and other Users).
We have had this error few times as well. I have not ruled out user error yet totally. Since I have not been able to trigger this deliberately.
For us also the created times are not close to identical, so it does not seem to be a problem of traffic.
I've been thinking this might be linked to the fact that PDM returns unused numbers back for use. For example if user gets a number for save window but cancels the save or generates numbers for copy tree but does not go through with it.
Don´t know how crashes or network errors affect the serial number "returning". Our problems in the past have been mostly with users at a remote office with a ping of less than 80ms.
Most users are not aware that the numbers get reused, so they might think its possible to copy paste the numbers they left "unused".
We use unique file names -setting inside PDM, but since we use same part numbering for parts & assemblies, it is possible for us to have same part number as part and assembly. This can cause alot of issues when exporting to ERP system, since basically someone can accidentally override someone elses part with same named assembly.
We are using 2017 SP3@server and SP4.1 at clients. We have also very simple serial number adding generating the numbers.
In your screenshot, the first assembly has file extension as lowercase, and the later have the extension as capital letter. In my experience Solidworks saves file extension with capitals. But users can write the extension lower case. Do you think it could be possible first user was "reusing" a part number by typing filename manually and the second got a recycled serial number from the system? Edit: I just noticed you wrote that the first user did not manually renamed, that makes this more intresting for sure . I'll try to remember report back my next problem with the serial number when we have one.
I think your issue is reported in SPR 769689 which was fixed in 2016. This is a problem with assemblies that produce reference dialogs when doing a save as and the user hitting cancel on those causing the serial number to end up getting pushed back to the top of the stack to be used again.
we are working on SWX 2017 SP2 on the PDM server and SWX 2017 SP2 or SP5 on the clients.
We have the same problem: From time to time two different users working on two different workstations produce within a short period of time (minutes) identical serial numbers. Since we do not allow identical file names in the vault we have the case that these are a part and an assembly file (just as Ville Makinen was mentioning) , and for that reason it can stay unrevealed for a long time.
I exclude human failure in this cases for sure.
Once I have observed the following: The PDM refused to increase the serial number for an user when executing the "save as" command within the vault. After I logged-in on his machine with my PDM account, the PDM worked as predicted, then immediately logged-off, and the serial number generator generated the appriopriate number with the PDM account of my colleague...sometimes the PDM system does need an extra kick in the ass I suppose !
It could of course be related with network issues, but in my opinion there should be a logic within the PDM to avoid it. Or some kind of query in the background to report those issues, let say within two days.
Just in case anyone stumbles onto this looking for why it's still happening, this issue has popped back up as SPR 1107205 in 2018 SP2 and has been verified to still be there all the way into 2019 SP0