Latest version is not the same on 3 PCS

[mp3-250]

This is something that happens like once every 2 years, so not so much experience to speculate about.
I have a big cabinet assembly with a small sub assembly for simple a signal alarm tower.
On one PC the alarm tower sub assy opens just fine. On other two PCs the sub assy is full of mate errors.
Same errors on both PCs I tried:
- to clean the local cache
- to look for and delete all local files
- to force rebuild the sub assembly and checkin overwriting the latest version
-to get latest version multiple times
- I tried to copy on the desktop the PDM files and they open just fine. Overwritten the latest version with those files on the desktop and still a faulty assy for two machines


Nothing changed one PC shows no problems while on the other two we have mates errors.
Same vault two different users, different results even for the same user on two different PCs

I remember 2 times I had a similar problem and ended up to rebuild bottom up the top assembly to fix what appeared a faulty data... but why on one PC it works and not on the others?

My guess: I suspect the references in the sub assy are messed up, probably with some termporary file that used to be outside our vault like on the desktop, but I cannot find proof of this speculation looking at where the file reference are loaded. Everything seems normal, and It does not make sense since the server latest should be the same on every PDM client.

[CarrieIves]

Do the computers have different settings?

Check the option Tools > Options > System Options > Messages/Errors/Warnings, "Treat missing mate references as errors".
Turned on you get errors. Turning this option OFF does not display the errors when you open an assembly with mate errors with missing references.

We found that configurations couldn't be made happy with this option on for some of our assemblies.

[AlexLachance]

Have you looked at a specific mate to see how it reacts on the one where it opens just fine? I suspect CarrieIves is correct.

[mp3-250]

Do the computers have different settings?

Check the option Tools > Options > System Options > Messages/Errors/Warnings, "Treat missing mate references as errors".
Turned on you get errors. Turning this option OFF does not display the errors when you open an assembly with mate errors with missing references.

We found that configurations couldn't be made happy with this option on for some of our assemblies.

we have that check enabled on all the machines. opening the same file version I expect them to behave the same: same files, same settings.

anyway worth a try.

[mp3-250]

Have you looked at a specific mate to see how it reacts on the one where it opens just fine? I suspect CarrieIves is correct.

they are completely fine on one pc and totally messed up (not finding geometry) on the othet machines.
they seem to load different data from the pdm server.

[rodface]

I would check the reference/file locations/search paths for the 3 different PCs. Are there any differences in them? Could some of the PCs be opening the file not from PDM but from another location? Could it be that one of these users has a difference in their permissions that is causing them to be unable to see the file in PDM and thus their SW is checking its search paths and finding an older version of the assembly elsewhere? Or perhaps in a different location in PDM, if you are allowing duplicate filenames? If any of the above is true I would think that you could detect it by looking at the tree in the PDM add-in on each PC or checking File>External References.

Just some thoughts, you may have already ruled out these points.

[mp3-250]

I would check the reference/file locations/search paths for the 3 different PCs. Are there any differences in them? Could some of the PCs be opening the file not from PDM but from another location? Could it be that one of these users has a difference in their permissions that is causing them to be unable to see the file in PDM and thus their SW is checking its search paths and finding an older version of the assembly elsewhere? Or perhaps in a different location in PDM, if you are allowing duplicate filenames? If any of the above is true I would think that you could detect it by looking at the tree in the PDM add-in on each PC or checking File>External References.

Just some thoughts, you may have already ruled out these points.

This is the first thing I have looked at and all pointed inside the same PDM folder path.
I have extracted the files from every PC local cache and the path was the same.
The raw latest version that I extracted from the server archive (not a vault view, but the HEX FileID folder with all the versions) opens fine on all machines, so the very same file should be saving on those PCs after a GET LATEST, but it is not or it is altered in a strange way.

Anyway I have tried to clear the local for every PC and ALL are getting a corrupted latest version. No user dependent, no PC dependent. If you try to fix the file from one PC it works on that PC until you clear the cache and still corrupted on others. I suspect something is not updating in the database, while it is inside the file itself as for references or whatever.


Comparing the files from the archive server and the 3 pcs I discovered that while 1 pc was opening fine its file was exactly the same as the one in the archive server (as expected) while the other 2 pcs were getting something different (different files size different content) from ... god knows where? If it was a past version it would be the same for both the pcs that shown the errors after opening the file, my suspect is the latest version is downloaded from the PDM server then corrupted locally for some kind of reason.

[rodface]

One cannot rule out odd network-related corruption as files go to/from client and server. We observed this very thing happen during check-ins and traced it to some settings in our VPN (Zscaler), the file would corrupt during the check-in to the server so the file creator had the only good copy, the server and any other clients that fetched the file had identical corrupt copies. PDM was not "aware" of this in any way.

I would of course be surprised if this sort of corruption happened repeatedly and was not random/intermittent but anything is possible...

[zxys001]

guessing maybe possible,.. VOR?

[mp3-250]

UPDATE
like another couple of cases I remember this one ended in the same way. a forth user was involved in the process and that user was the one that created the versions 1 to 3, my colleague edited version 4 and thay version is broken, but not inside the archive server. that raw file if opened in SOLIDWORKS is just fine.

I tried to fix that version4 with 3 pcs fixing the errors and overwrite latest at check in. it worked for the pc that did it, and on the other 2 pcs still the same error after clearing theit cache and getting latest. same the pc the did the fix clear the cache get latest again and boom again the error in the assy. AGAIN.

until yesterday the user that made the file check it out and made version 5: everybody get a error free latestas expected.
if you get the old version 4 from a client, it is broken again and the very file that is saved into the local cache is not a copy of the file on the archive server.

my guess is that a client uploads some broken data on the server, and for some strange reason that corrupted data is corrupted only after downloading in any othet pdm client than the one the created the file.

now I have the version 5 on my server EVERY pdm client is downloading and storing locally the exact same file we have into the archive server. same size same content up to the last bit.
with version 4 is different and clients get a different file size and content from the one into the archive server.

[bnemec]

Couple of things come to mind.

When you were checking file references on the file versions, were you checking them from in Solidworks on each machine with the assembly loaded? While the file does contain a suggestion of file ref path, SW likes to find the file how it likes to find the file. Did someone have more copies of a referenced file with the same file name squirreled away somewhere on that local disk or network shares and the SW on that machine is grabbing it from there?

Do you have a replication server and is it possible one machine is pulling from that replication server while the others are on master? I assume if so you would have checked the version 4 file on the replication archive server too.

[mp3-250]

Couple of things come to mind.

When you were checking file references on the file versions, were you checking them from in Solidworks on each machine with the assembly loaded? While the file does contain a suggestion of file ref path, SW likes to find the file how it likes to find the file. Did someone have more copies of a referenced file with the same file name squirreled away somewhere on that local disk or network shares and the SW on that machine is grabbing it from there?

Do you have a replication server and is it possible one machine is pulling from that replication server while the others are on master? I assume if so you would have checked the version 4 file on the replication archive server too.

SW support asked us about replication server as well.
no we have only one production server and a test server which does not host this assy at all since it was made from a older backup.

my colleague swapped some files in that problematic assy at some point so I thought they were loaded from some other place, like his desktop, BUT the same happens on my pc and another I use for training, so local files are unlikely on 3 different pcs. we cleared local cache and local files as well.

one more thing I checked under file > references and the assy is indeed pulling components from the vault and not from some random folder.

I have extracted the assy file from the vault local cache, from each pc and from the archive server copied on my desktop and renamed them.
the assy copy into the archive server opens just fine and reference the components inside my vault view and the same for other pcs as well.

all the other assy from the other local caches that were pulled from the archive server are just "corrupted" and try to load a slightly different component tree.

just to make a practical example

archive server hosts 00000004.sladasm which, let's say, it is 156.1 kb in size. (not in front of my pc now)

get latest performed on 3 pcs results in 3 different file sizes on each pc.
I confirmed with double commander, browsing into the vault.

clear the cache > folder empty

get latest > file downloaded from archive server, but wrong size

now we had a 4th user, the one that created the file and firstly checked into the vault. that user made version 5 the other day.

archive server hosts 00000005.sladsm and assume its size 161kb

get latest in each pc get a 161kb file and they are the EXACT copy of the file stored into the archive server.

why get ver4 is not the same as the archive server? it is "corrupted" every time we get latest apparently.
ver5 is just fine. same file on every pc and the server...

I suspect there is a scary bug going around. my gut feeling.
I do the helpdesk support for SW inside our company, so it happens I walk around and see other workstations and sometimes even if you get latests and open the same files they have a slightly different tree, like a minor error here and there, or a rebuild pending, compared to what I see on my workstation.

They have the same base settings as my workstation, same model with same specs, deployed from the same admin image. I started to think that there is something wrong going on, at least in our PDM system.

[bnemec]

Just ruling out a dumb question, duplicate file names are prohibited in your vault right?

Local cached file size being different than the archive is perplexing. You say it's "corrupt" but then that they open with different component tree. To me "corrupt" means file doesn't open or has bad behavior. Different file size feels like we're caching a file different than what's in the archive server.

Does the index.xml in that archive folder look good? What happens if you rename the 00000004.sldasm to something else then try to cache it on a client PC. It's probably a dumb test but hopefully we get archive error.

Have you queried the Documents table for that filename to check if there's something in there, maybe deleted doc by that file name.

We've had slightly similar quirkiness when a file was renamed (movetree) but had checked out parents on client PCs, those did not clear their cache of the old file name. I think we've discussed deleting read only files that are not in the vault before, I think it required browsing into the folder it was cached in. Anyway, Solidworks was using that old local copy that wasn't in the vault, essentially, it was using an old version of that file.

Only other thing that comes to mind is how PDM updates refs and file properties when caching the file or checking it out, based on SQL data. Could that explain the difference between cached file and the one in archive? If there are a lot of configs or design table driven configs maybe? You're not using some automated configuration tool like driveworks are you?

[mp3-250]

Just ruling out a dumb question, duplicate file names are prohibited in your vault right?

Local cached file size being different than the archive is perplexing. You say it's "corrupt" but then that they open with different component tree. To me "corrupt" means file doesn't open or has bad behavior. Different file size feels like we're caching a file different than what's in the archive server.

Does the index.xml in that archive folder look good? What happens if you rename the 00000004.sldasm to something else then try to cache it on a client PC. It's probably a dumb test but hopefully we get archive error.

Duplicates are forbidden for most file extensions (SW files)
I actually did this test.

1. clean local cache for the assy file (checked with double commander that the file wwas gone from my disk)
2. log out from vault
3. copy 00000004.sldasm into the local cache renaming it exactly as the local file is expected
4. login in the vault
5. explorer version tab = 4/4 recognize the file as latest version
6. open the file as usual -> it opens perfectly from the local cache NO ERRORS

the file must be identical to the one in the archive server, even the date must match otherwise the local file is seen as "green clock icon" -/4

As soon as I clean the local cache and "get latest" again the file opens with errors and it is not the 00000004.SLDASM on the server, but something else. That something else has a different file size for every PC, this is why I am saying it is "corrupted", it is not the same content. Like the get latest is truncating the file, but the error is the same for all pcs.

The new version that a user made the other day is fine and get latest literally gets the latest 00000005.SLDASM in the server.

Have you queried the Documents table for that filename to check if there's something in there, maybe deleted doc by that file name.

We've had slightly similar quirkiness when a file was renamed (movetree) but had checked out parents on client PCs, those did not clear their cache of the old file name. I think we've discussed deleting read only files that are not in the vault before, I think it required browsing into the folder it was cached in. Anyway, Solidworks was using that old local copy that wasn't in the vault, essentially, it was using an old version of that file.

We use search local files to locate theam and I have a excel sheet that extract and open the paths to autoclean the local files. We used it to avoid local files from opening in addition we cleaned the local cache too to force the server version.

Only other thing that comes to mind is how PDM updates refs and file properties when caching the file or checking it out, based on SQL data. Could that explain the difference between cached file and the one in archive? If there are a lot of configs or design table driven configs maybe? You're not using some automated configuration tool like driveworks are you?

No, we do not use DriveWorks or special tools.
I have not touched or looked at the SQL tables yet, I was hoping my VAR to suggest use where to check into the DB, but I think at this point is better take a look by ourseleves.

As for the structure of the assy is a simple single configuration file: an alarm lamp with 5 or 6 colored cilindrical lights stacked on each other and a pole with a bracket at the base. A component we buy from PATLITE and arranged in a certain order for a certain machine we are making.

Unfortuantelly I cannot access this forum from my workplace so even if this is a commercial component without our IP I cannot upload it here and there are company policies that prevent me to do so as well...[rolls eyes]

[mp3-250]

One cannot rule out odd network-related corruption as files go to/from client and server. We observed this very thing happen during check-ins and traced it to some settings in our VPN (Zscaler), the file would corrupt during the check-in to the server so the file creator had the only good copy, the server and any other clients that fetched the file had identical corrupt copies. PDM was not "aware" of this in any way.

I would of course be surprised if this sort of corruption happened repeatedly and was not random/intermittent but anything is possible...

I saw late your comment.
thank you very much, I appreciated the information.

the user that made the file was indeed working remote from a vpn enabled client, but only using remote desktop to connect to the workstation that is here in the company office connected to our pdm server and it should not be supposed to be affected by VPN. I think...

[bnemec]

It still feels like something is wrong in the database side with version 4.

You could try going into the index.xml file in that archive folder and say that version 4 ref version 5 ( I would temporarily rename the 00000004.sldasm file too). Then try to get version four. I would bet that you'll still have problems. As you stated, manually caching v4 from archive works fine so it's not the file in archive, is the sql data for that version.

If you have a good working version for going forward, I'd say good enough. Sometimes the how/why is not worth it, right now. Maybe leave the 00000004.sldasm file renamed so that if a user tries to get version 4 the archive will not let them.

[mp3-250]

I undestand your pragmatism and yes, we "solved" it with ver5. =)

My VAR is making me crazy to file a request to look in those files, but I have a bad feeling that something very wrong is going on in our vault and I want SW to check and compare at least those files. 00000004.SLDASM and the locally cached one at least or to just tell us what to look at to be sure there is not a data corruption like the user above said in the VPN comment.

It is like that time with the "rollback with references" that was not supposed (per SW admission) to rollback files without telling you "what and where" before doing it and making your assemblies implode...They told us "Uh, please refrain to use that option when rolling back" ... I do not think the risks are even written in the manual, let alone no warning in the UI.

In our case if there is a risk of file corruption, I would prefer SW to be aware of it at least, and advise us how to avoid it.

It still feels like something is wrong in the database side with version 4.

You could try going into the index.xml file in that archive folder and say that version 4 ref version 5 ( I would temporarily rename the 00000004.sldasm file too). Then try to get version four. I would bet that you'll still have problems. As you stated, manually caching v4 from archive works fine so it's not the file in archive, is the sql data for that version.

If you have a good working version for going forward, I'd say good enough. Sometimes the how/why is not worth it, right now. Maybe leave the 00000004.sldasm file renamed so that if a user tries to get version 4 the archive will not let them.

When I rebuild the test server I would try to swap the files in the index.xml

[xellentia]

Try run a query on the Documents table and see what it has as the latest version. I believe that value is what drives the “get latest” action, I,e,. Which file to grab from the archive server.

If it points to the right file, there is an also table that tracks file renames (sorry, I don’t remember the table name, but it is easy to spot). Query into it to see if the file name was once used on a different file… if it was, pdm might have been confused.

Also, check the error log in the Administration tool on the PCs that have problems. It might have captured some error.

[mp3-250]

Try run a query on the Documents table and see what it has as the latest version. I believe that value is what drives the “get latest” action, I,e,. Which file to grab from the archive server.

If it points to the right file, there is an also table that tracks file renames (sorry, I don’t remember the table name, but it is easy to spot). Query into it to see if the file name was once used on a different file… if it was, pdm might have been confused.

Also, check the error log in the Administration tool on the PCs that have problems. It might have captured some error.

there was no error in both the local and server log inside administration tool.

the latest version was updated by the user that made the filecand now it is ok. the 4th version is still got as "corrupted" last time i tried on the machines. Every client I tested had a slightly different file size compared to correct file in the server and other pdm clients. I need to see with process monitor what is going on. I suspect our antivirus in action.

I had a pdm addin .caf non able to decompress its dll inside multiple local vaults unless you retry 2 or 3 times to enter the vault.
at some point that problem went away by itself. (antivirus update??)

[jcapriotti]

@mp3-250 Are you using PDMs file compression on your Archives?

[mp3-250]

@mp3-250 Are you using PDMs file compression on your Archives?

no we are not using compression.