![cant..believe... o[](./images/smilies/brickhead.gif)
So how badly did i get screwed by installing it while it was available?
![grumph grumph](./images/smilies/e21589.gif)
Anyone ask why it was pulled over at the forum that shall remain unnamed? This seems like one of those questions that belongs over there.Bradfordzzz wrote: ↑Thu Jun 17, 2021 12:54 pm They have removed this service pack from downloads ....![]()
So how badly did i get screwed by installing it while it was available?![]()
I just tried to post something about this over there admonishing them for not telling us anything. It hasn't been posted yet.
Yeah, but no one over here works for DS and probably wouldn't have direct information of why it was pulled.Bradfordzzz wrote: ↑Thu Jun 17, 2021 3:17 pm I don't go over there anymore. Pointless when anyone I actually want to discuss issues with are all here.![]()
Wait?! You published a post and it didn't post? That seems weird I didn't think they were moderating over there or is the forum just plain broke again?
I originally posted in the SWX Connect community instead of the User Forum community. I posted there because that is where we are supposed to get information from them, whereas the forum is more user-to-user. It turns out I do not have author status for that section. Silly me.
So somehow they actually broke one of Solidworks worst habits which is that it looks all over the place and rather randomly decides which file to use. I wonder if they will "Fix it" by having SW resolving to "Mehhh, something close"Frederick_Law wrote: ↑Thu Jun 17, 2021 4:31 pm Creating circular links:
https://r1132100503382-eu1-3dswym.3dexp ... Ej6H8TaQuw
https://www.solidworks.com/sw/support/C ... etins.html
Do you mean when the referenced file is stored in the parent file by full path but Solidworks FIFY by finding that filename in whatever directory it thinks is best?
It's not random. It's a poorly thought out 'routinre' that I'm convinced is a conglomeration of 'we need this' requests from large customers.
It's a glaring but fairly innocuous bug. If you open a file that's missing references, this dialog pops up as normal:Bradfordzzz wrote: ↑Thu Jun 17, 2021 12:54 pm They have removed this service pack from downloads ....![]()
So how badly did i get screwed by installing it while it was available?![]()
Yes, this is one of the things that I think makes SW unstable. Coming from IV where "Projects", files, file locations, file links etc etc where fairly robustly enforced...Solidworks scared me from day one in this regard.
Yes it's not random....just a really bad idea on how to decide what files should be in an your assembly. I prefer a step of 1..."This is the file that should be here." rather than "Well this is the file that is supposed to be here but it does not appear to be here so let me run all over this disaster of a file structure you have here pretending I know how it works even though you don't know how it works so I can decide which one I think is supposed to be here"JSculley wrote: ↑Thu Jun 17, 2021 6:32 pm It's not random. It's a poorly thought out 'routinre' that I'm convinced is a conglomeration of 'we need this' requests from large customers.
It's down to 8 steps from 13 back in SW2013, so it's 'improving', I guess.
Solid Edge has a goofy way of looking for files as well, feels kinda like how SW does it. What I don't understand is why using the path that is stored in the parent file is so far down the list.MJuric wrote: ↑Fri Jun 18, 2021 9:25 am Yes it's not random....just a really bad idea on how to decide what files should be in an your assembly. I prefer a step of 1..."This is the file that should be here." rather than "Well this is the file that is supposed to be here but it does not appear to be here so let me run all over this disaster of a file structure you have here pretending I know how it works even though you don't know how it works so I can decide which one I think is supposed to be here"![]()
That's pretty much what Inventor does. Not only that but the files are limited to "Project space". The file not only has to be where you tell it to be but that path also has to be with in the project space definition. So you can't randomly place a file somewhere and then tell IV to include that file in the assembly because it will tell you, "Uhhh, nahhh, I'm not making this assembly a mish mash of file locations that will end up looking like your desktop....yes I've seen your desktop, it's a mess and I'm not letting that happen here so shape up!"bnemec wrote: ↑Fri Jun 18, 2021 10:00 am Solid Edge has a goofy way of looking for files as well, feels kinda like how SW does it. What I don't understand is why using the path that is stored in the parent file is so far down the list.
If I could choose (thank goodness I cannot) it would be a 3 step process. CAD would do this when opening a file with references.
1) Is that filename already loaded in memory? ( I can accept this one is mandatory for reasons that are over my head)
2) Is the file in the EXACT PATH stored in the parent file I'm opening?
3) Display dialog, "Referenced file path {full file path as stored in the parent file} does not exist, please fix your $#!+."
Done, that's it. If you renamed your file server then use one of the existing tools to update all the refs in all the files, don't change default behavior of the program. Any Solid Edge user that became comfortable with Revision Manager, now Design Manager, knows what a good tool for fixing missing/broken refs looks like.
Number 1 irks me to no end. A file is not a file name. It is a path and a file name. I can have 100 files named A.SLDPRT in the file system, provided that they have different paths. SOLIDWORKS throws the path information out the window and disallows not only having two files with the same name but different paths in an assembly, but complete disallows opening two different files just because they have the same name.bnemec wrote: ↑Fri Jun 18, 2021 10:00 am Solid Edge has a goofy way of looking for files as well, feels kinda like how SW does it. What I don't understand is why using the path that is stored in the parent file is so far down the list.
If I could choose (thank goodness I cannot) it would be a 3 step process. CAD would do this when opening a file with references.
1) Is that filename already loaded in memory? ( I can accept this one is mandatory for reasons that are over my head)
2) Is the file in the EXACT PATH stored in the parent file I'm opening?
3) Display dialog, "Referenced file path {full file path as stored in the parent file} does not exist, please fix your $#!+."
Done, that's it. If you renamed your file server then use one of the existing tools to update all the refs in all the files, don't change default behavior of the program. Any Solid Edge user that became comfortable with Revision Manager, now Design Manager, knows what a good tool for fixing missing/broken refs looks like.
That part about (Files must be in the Project" folder) makes me throw up in my mouth a little. Mostly because ~75% of my CAD experience is in an environment where "projects" have a finite lifespan "files" live on as a product of the project. New "Projects" use ~85% existing files that were created by a "project" that was put to bed 1 to 20 years ago. So if we were using IV, a "project" by CAD definition would have to be our entire data set. Which would at least keep people from saving stuff in the wrong network share or on C drive or a USB stick.MJuric wrote: ↑Fri Jun 18, 2021 10:20 am That's pretty much what Inventor does. Not only that but the files are limited to "Project space". The file not only has to be where you tell it to be but that path also has to be with in the project space definition. So you can't randomly place a file somewhere and then tell IV to include that file in the assembly because it will tell you, "Uhhh, nahhh, I'm not making this assembly a mish mash of file locations that will end up looking like your desktop....yes I've seen your desktop, it's a mess and I'm not letting that happen here so shape up!"
The approach takes a bit of additional work and a whole lot more structure but in the end, in my experience, it ends up in a whole lot better stability and much better "Part to part" link and function. Some things that make SW choke IV does without issue because it doesn't have to go thru a rehab 12 step process to find the files it need to work with.
Take all of that with the idea that I haven't worked with IV for five or six years and apparently we forget or remember incorrectly something like 50% of what we know from year to year....so there's that.
I agree, our files aren't stored by "Project". At most maybe "Product" but our product have many shared components. In IV we could only have one project I assume for that to work? In that case, wouldn't you have the same problem SolidWorks can have? Multiple copies floating around and the wrong one gets loaded?bnemec wrote: ↑Fri Jun 18, 2021 11:45 am That part about (Files must be in the Project" folder) makes me throw up in my mouth a little. Mostly because ~75% of my CAD experience is in an environment where "projects" have a finite lifespan "files" live on as a product of the project. New "Projects" use ~85% existing files that were created by a "project" that was put to bed 1 to 20 years ago. So if we were using IV, a "project" by CAD definition would have to be our entire data set. Which would at least keep people from saving stuff in the wrong network share or on C drive or a USB stick.
With IV you can define "Libraries" as part of the Project area definition. If 90% of a new project was the same as a previous one just add that directory to the libraries.bnemec wrote: ↑Fri Jun 18, 2021 11:45 am That part about (Files must be in the Project" folder) makes me throw up in my mouth a little. Mostly because ~75% of my CAD experience is in an environment where "projects" have a finite lifespan "files" live on as a product of the project. New "Projects" use ~85% existing files that were created by a "project" that was put to bed 1 to 20 years ago. So if we were using IV, a "project" by CAD definition would have to be our entire data set. Which would at least keep people from saving stuff in the wrong network share or on C drive or a USB stick.
"Project" in IV is little more than defining where everything is. You essentially have a working project folder where all the new stuff automatically goes and then you can add "Libraries" which are nothing more than "directories where other stuff is". You can't have any duplicate files in a project so IV doesn't go looking for another file if it's not where you said it was.jcapriotti wrote: ↑Fri Jun 18, 2021 5:15 pm I agree, our files aren't stored by "Project". At most maybe "Product" but our product have many shared components. In IV we could only have one project I assume for that to work? In that case, wouldn't you have the same problem SolidWorks can have? Multiple copies floating around and the wrong one gets loaded?
So this thread is back to kicking Solidworks for releasing crappy Service Packs?
Yeah, I guess. If that's really how you want to spend your time. I give you all a hard time about bitchin now, but Paul Salvador is probably laughing his @$$ off at me, or at least scratching his head a little bit wondering if I hit my head or got religion or what happened?!?!?
Speaking of rails, I wonder who will be ridden out on one?matt wrote: ↑Tue Jun 22, 2021 2:14 pm Yeah, I guess. If that's really how you want to spend your time. I give you all a hard time about bitchin now, but Paul Salvador is probably laughing his @$$ off at me, or at least scratching his head a little bit wondering if I hit my head or got religion or what happened?!?!?
We could try to run this thread off the rails a second time and have to split it out to Kitty Dump...![]()
Hopefully the second.matt wrote: ↑Tue Jun 22, 2021 2:14 pm Yeah, I guess. If that's really how you want to spend your time. I give you all a hard time about bitchin now, but Paul Salvador is probably laughing his @$$ off at me, or at least scratching his head a little bit wondering if I hit my head or got religion or what happened?!?!?
We could try to run this thread off the rails a second time and have to split it out to Kitty Dump...![]()
@Bradfordzzz, would you mind modifying the title of the thread to append ", but SP4.1 IS (June 24, 2021)", or something similar?Bradfordzzz wrote: ↑Thu Jun 17, 2021 12:54 pm They have removed this service pack from downloads ....![]()
So how badly did i get screwed by installing it while it was available?![]()
Because.....mattpeneguy wrote: ↑Fri Jun 25, 2021 8:17 am All right beta testers...on my mark, ready...set...GO!
Wait...why did I mark that as sarcastic?...
Nice. Thanks Tim!Tim R. Halvorsen wrote: ↑Sat Jun 26, 2021 1:40 am For those who already installed the SP4, there is a hotfix available:
https://www.solidworks.com/sw/support/hotfixes.htm
Tim
Just upgrade to 4.1. working fine with this service pack for me. (disclaimer to that statement ... we don't use PDM so I can't speak to that)jmongi wrote: ↑Wed Jul 07, 2021 9:14 am Well, this is great. We hadn't upgraded for forever and a few weeks ago we renewed our subscription and installed the latest with assistance from our VAR. I should have known there was going to be issues when the support tech went to install SP3.0 (which is what it was tagged as) and the installer pulled SP4.0. Never good when the VAR is confused.
So, what's the deal. Fortunately I haven't done much SW work since then. What is the bug/issue and how do I fix this before I break something?