FVUT here we go again
FVUT here we go again
While I am not a fan of configurations for part files, I have to deal with them as we have our standard catalog parts and hardware using them for legacy reasons.
Last time (sw2022) I tried the file version upgrade tool (FVUT) it failed
on some conversion still flagging the file as successfully converted in the DB. A bug still open in sw2023.
This time I tried to avoid the cause that lead to most failures and focussed only on the latest version of part files: some warning, but no errors on our test server.
All good unless I noticed that only the active configuration was rebuild. This is causing some of our models with dozen of configurations to take more time to load into their assemblies (like 30% slower compared to the same model with all configurations rebuilt).
Last year I just gave up using this tool, abd probably this year too. We have around 10k parts to upgrade some of them still on a 10yrs old file format.
If I have to rebuild by hand every file with CTRL+SHIFT+Q and checking them back overwriting the latest version in PDM, FVUT is basically useless.
Still waiting a reply from my VAR about this issue.
Last time (sw2022) I tried the file version upgrade tool (FVUT) it failed
on some conversion still flagging the file as successfully converted in the DB. A bug still open in sw2023.
This time I tried to avoid the cause that lead to most failures and focussed only on the latest version of part files: some warning, but no errors on our test server.
All good unless I noticed that only the active configuration was rebuild. This is causing some of our models with dozen of configurations to take more time to load into their assemblies (like 30% slower compared to the same model with all configurations rebuilt).
Last year I just gave up using this tool, abd probably this year too. We have around 10k parts to upgrade some of them still on a 10yrs old file format.
If I have to rebuild by hand every file with CTRL+SHIFT+Q and checking them back overwriting the latest version in PDM, FVUT is basically useless.
Still waiting a reply from my VAR about this issue.
Re: FVUT here we go again
After upgrading the parts in our test vault I tried to upgrade the few hundreds assy we have inside the catalog parts. it seems to work, but during the conversion some assy di not loads their components (tree component greyed out) or show the tree full of errors (red X marks).
I tried to open some of those files and they look fine, so I am not sure what the heck is going on during the conversion. KB hints to a local cache failing to cache the necessary components, but this is supposed to be an admin tool we shoul rely on to keep our data fine and well ...
I tried to open some of those files and they look fine, so I am not sure what the heck is going on during the conversion. KB hints to a local cache failing to cache the necessary components, but this is supposed to be an admin tool we shoul rely on to keep our data fine and well ...
Re: FVUT here we go again
Not sure if it would help in your case but you might be able to semi-automate it with the SW Task Scheduler Convert Files operation, which has the option to "Activate all configurations before saving". You'd still have to do the check-out & check-in steps manually, and it doesn't have any PDM-specific support like moving revision tags or updating all versions.
Re: FVUT here we go again
officially SW says that task scheduler does not support PDM and FVUT must be used instead. they even removed a PDM tool that was included in t.s. back in 2018 apparently for the same reason.
I can imagine how to use t.s., being careful to get ltest version of the files, check them out manually, and run the batch on the local cache then check them back.
one problem with this approach is that no backup of the latest version we are going to overwrite is created in the archive server automatically.
also a problem in our case seems to be related to the age of our files or their templates. files made last year rebuilt correctly in all configurations even with FVUT, the rest seems to be a mess.
FVUT has the same activate all configurations before saving like task scheduler, but with some files it does not work and for other it works. I should give it a try to task scheduler anyway. thanks
also FVUT fails to update some file and write them as a success in both the DB and the log file. a known SPR still open.
I can imagine how to use t.s., being careful to get ltest version of the files, check them out manually, and run the batch on the local cache then check them back.
one problem with this approach is that no backup of the latest version we are going to overwrite is created in the archive server automatically.
also a problem in our case seems to be related to the age of our files or their templates. files made last year rebuilt correctly in all configurations even with FVUT, the rest seems to be a mess.
FVUT has the same activate all configurations before saving like task scheduler, but with some files it does not work and for other it works. I should give it a try to task scheduler anyway. thanks
also FVUT fails to update some file and write them as a success in both the DB and the log file. a known SPR still open.
-
- Posts: 2
- Joined: Thu Jan 11, 2024 12:48 pm
- x 7
Re: FVUT here we go again
From What's New 2020
Re: FVUT here we go again
We have already that opion activated, but I can guess it affects only SAVE time. and that is fine, but the main issues here is that we have 10yrs old data that need to be updated. their file structure is getting too old and potentially broken.CharlesGrey wrote: ↑Fri Mar 15, 2024 8:23 am From What's New 2020
2020 Batch Conversion Not Required.png
Also an assy, independently of that save option will load and convert every old file in the memory space to thr latest SW available in your system.
it could be that keeping that option disable actually disrupt the conversion batches as I witnessed the other day during our tests.
Re: FVUT here we go again
we got SW official reply which sounded like:
LOL everything works as expected. Still on pre 2019 files?
LOL you need to
open them one by one and set rebuild on save on each configuration, otherwise we rebuild only the active one.
LOL no problems here get away.
I may add that after their botched conversion to 2023 the SHIFT+CTRL+Q combo works as expected rebuilding all configurations without any flag added to the configurations before the rebuild.
Am I missing something?
LOL everything works as expected. Still on pre 2019 files?
LOL you need to
open them one by one and set rebuild on save on each configuration, otherwise we rebuild only the active one.
LOL no problems here get away.
I may add that after their botched conversion to 2023 the SHIFT+CTRL+Q combo works as expected rebuilding all configurations without any flag added to the configurations before the rebuild.
Am I missing something?
- AlexLachance
- Posts: 2187
- Joined: Thu Mar 11, 2021 8:14 am
- Location: Quebec
- x 2373
- x 2015
Re: FVUT here we go again
Push them again, they gave me that reply in 2016 saying it would fix an issue. It was a partial fix that sometimes worked, sometimes didn't and it caused a bunch of other minor issues afterwards.mp3-250 wrote: ↑Mon Mar 18, 2024 5:49 pm we got SW official reply which sounded like:
LOL everything works as expected. Still on pre 2019 files?
LOL you need to
open them one by one and set rebuild on save on each configuration, otherwise we rebuild only the active one.
LOL no problems here get away.
I may add that after their botched conversion to 2023 the SHIFT+CTRL+Q combo works as expected rebuilding all configurations without any flag added to the configurations before the rebuild.
Am I missing something?
If that was what caused the issue, that "feature" would or should have long been locked since but it still is a toggling switch. It's just Dassault being lazy as usual in both their responses and fixes.
Heck, they provided a "fix" for us but still haven't adressed the issue. I'm on 2023 SP4 right now and we are:
Still getting the issue of SolidWorks mixing up references between files in properties. (Reassign the reference directly to fix)
Still getting the issue of drawing views of parts showing original part that was used to make the new one. (change display state and come back to fix)
Still getting the issue of drawings not updating BOM references internally, so you end up with a warning that it can't find X file in a drawing prompting you to delete or reassign the reference, only to have nothing happen no matter what you do. (Delete BOMs and recreate them to fix)
Those bugs also exist on SP5
Re: FVUT here we go again
If you aren't familiar with it, I would investigate #Task from Central Innovations. I'm pretty sure it will do what you want, including rebuilding all configurations.
https://centralinnovation.com/solidwork ... s/task-v2/
https://centralinnovation.com/solidwork ... s/task-v2/
-
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
Re: FVUT here we go again
do you have a SPR number for those issues? they sound scary...AlexLachance wrote: ↑Tue Mar 19, 2024 8:30 am Push them again, they gave me that reply in 2016 saying it would fix an issue. It was a partial fix that sometimes worked, sometimes didn't and it caused a bunch of other minor issues afterwards.
If that was what caused the issue, that "feature" would or should have long been locked since but it still is a toggling switch. It's just Dassault being lazy as usual in both their responses and fixes.
Heck, they provided a "fix" for us but still haven't adressed the issue. I'm on 2023 SP4 right now and we are:
Still getting the issue of SolidWorks mixing up references between files in properties. (Reassign the reference directly to fix)
Still getting the issue of drawing views of parts showing original part that was used to make the new one. (change display state and come back to fix)
Still getting the issue of drawings not updating BOM references internally, so you end up with a warning that it can't find X file in a drawing prompting you to delete or reassign the reference, only to have nothing happen no matter what you do. (Delete BOMs and recreate them to fix)
Those bugs also exist on SP5
Re: FVUT here we go again
thank you for the suggestion.SPerman wrote: ↑Tue Mar 19, 2024 8:38 am If you aren't familiar with it, I would investigate #Task from Central Innovations. I'm pretty sure it will do what you want, including rebuilding all configurations.
https://centralinnovation.com/solidwork ... s/task-v2/
We have a quite tedious process for introduce a new piece of software.
If there was a reseller in Japan it would be a bit easier. maybe...
- AlexLachance
- Posts: 2187
- Joined: Thu Mar 11, 2021 8:14 am
- Location: Quebec
- x 2373
- x 2015