Reporting errors frowned upon?

Discussion created by Lars Uhlenhaut on Mar 12, 2019
Latest reply on Sep 10, 2020 by Matt Juric

Like • Show 5 Likes5
Comment • 37

Our VAR does not seem to like us when we report bugs to him. We are told that we are by far the customer that costs the most time and effort. But, over 80% of the cases that we report are bugs (SW, PDM, Composer). Isn't that wanted? After all, you want to have a well-functioning system at some point and not always have to be annoyed. Or is this idealism illusory? Due to the bugs we already have capacity losses of approx. 30%. How is it with you? Are you reporting bugs and is your VAR pleased about that? Which bugs do you report and how?

Outcomes

35 Replies

1 2FirstPrevious

John Stoltzfus Mar 12, 2019 8:12 AM
Lars Uhlenhaut - After reading your comment it makes me appreciate our VAR a lot more. They would do anything to help... Might be a good time to contact the ownership of the VAR, if they feel that way, then it's time to get another VAR..
Like • Show 14 Likes14
Actions
Josh Brady Mar 12, 2019 8:27 AM
Sorry... Not enough info to answer.

How do you report bugs? Do you generally provide repeatable examples etc, or do you just say, "SolidWorks crashed again"?

Do you report the same bugs over and over? (could get annoying)

Do the bugs you report lead to new SPRs (meaning that SolidWorks actually acknowledges that it's a bug)? Or do you get added to existing SPRs?

As I understand it, VARs are the first line of defense between incompetent users and actual SolidWorks. Based on the forum content, there are a lot of users who find "bugs" because they don't know how to use the software. They've changed some setting or another and don't know how to get it back, they don't fully define sketches so things act in a way the don't expect, etc. VARs have to verify the behavior, confirm it is malfunctioning, check the SPR list, and only then report to SW. If you give crap examples that aren't repeatable, or your "bugs" are just incompetence, or you keep reporting the same bugs, or everything you report is already a known bug, then I can see how a VAR might get annoyed. You are generating a lot of work for them that doesn't really help anybody. On the other hand, if you are finding new bugs, providing good example files, and making it easy to reproduce the bugs on their end, it's easy for them to pass along and you are providing benefit for all SW users and your VAR is being an idiot.

From where I sit, I can't evaluate either of those, and this is certainly not meant to accuse you of being the crap customer. Those are just the two extremes that exist.
Like • Show 14 Likes14
Actions
Glenn Schroeder Mar 12, 2019 8:39 AM
Josh makes some excellent points. I've been using SW for 30+ hours per week for 10 years, and only report what I think are bugs to our VAR once or twice per year, and still probably 1/3 of those are something I've done wrong or didn't understand instead of bugs.
Like • Show 9 Likes9
Actions
Peter De Vlieger @ Glenn Schroeder on Mar 12, 2019 9:23 AM
Glenn,

Somehow I doubt you're using the Routing add-in
Like • Show 6 Likes6
Actions
J. Mather Mar 12, 2019 9:34 AM
Lars Uhlenhaut wrote:
Our VAR does not seem to like us when we report bugs to him.
So, report the bugs here in an open forum.
Let's see what you have!
Like • Show 9 Likes9
Actions
Lars Uhlenhaut @ Josh Brady on Mar 12, 2019 11:13 AM
Josh, I'm not one of those stupid users you mention. I have enough experience with SolidWorks to see if I have a bug or broken file in front of me.
If I send a file to the VAR that crashes three times in a row on the same action, I have a right that this issue is reported to SolidWorks and will not have to settle for a repaired file again. Especially since that does not solve the problem permanently. The simplest solution for the VAR. Instead, I get the repaired file with the comment "and now shut up". (not in these words, but analogously).
Usually I only send in errors once. Of course it may happen that after more than a year, I may report a mistake one more time, but only because due to the multitude of errors, I can no longer see that the error has occurred before. Furthermore, the error already should have been corrected by updates.
It can not be that users find "bugs" that are based on using the software. By "bugs" I understand crashes and misconduct of the software. If crashes occur due to incorrect operation of the software, then in my opinion the software has a bad error handling.
Furthermore, if I report an error, I do not know in advance if there is already an SPR for it. This research is the task of the VAR, we pay a lot of money for it. My job is to build machines, not to support software development. Nevertheless I spend a lot of time for this and don't see any cent for it.
Like • Show 10 Likes10
Actions
John Stoltzfus @ Lars Uhlenhaut on Mar 12, 2019 11:22 AM
Lars Uhlenhaut - Dollars and Cents won't make a difference.....

Do what J. Mather recommends and when you find an issue, bring it up to the forum and see if it's a real issue or a lame issue like Josh Brady mentioned...
Like • Show 5 Likes5
Actions
Lars Uhlenhaut @ J. Mather on Mar 12, 2019 11:38 AM
Since many of them are file specific, it is not practiable to send the files here.
Like • Show 3 Likes3
Actions
John Stoltzfus @ Lars Uhlenhaut on Mar 12, 2019 11:42 AM
Maybe a few screen shots with detailed typed information would be a good start.. Basically you have gotten us really curious of what you're issues are and what you call bugs, so the less you show, the more Josh Brady's comment starts to ring true.

Are your issues truly SW issues or a Shot Self in the Foot issue?
Like • Show 3 Likes3
Actions
Josh Brady @ Lars Uhlenhaut on Mar 12, 2019 11:43 AM
Apologies if you took offense.... Again, I had no intention of painting you as one type of user or the other. I have no idea. I just know that both exist. The VAR certainly has a job to do. Part of that is definitely to look up issues in the SPRs. It's not the user's responsibility to look those up.

If your VAR is worth anything, you have records of your communications with them. If you are submitting genuine issues, they have a responsibility both to you and to SolidWorks to treat you properly. If that is not happening, there is someone at SolidWorks who is in charge of VARs (my apologies, I don't know who that is or how to contact them). I am sure they would be interested and disappointed to hear of a customer being mistreated by their VAR.
Like • Show 8 Likes8
Actions
Walter Fetsch Mar 12, 2019 12:20 PM
Time to find a new VAR.
Like • Show 4 Likes4
Actions
Lars Uhlenhaut @ Lars Uhlenhaut on Mar 12, 2019 12:28 PM
Josh, I didn't feel offended. It's always unlucky to express once feelings in writing.
John, it doesn't help if I upload files here > 1 GB here.
Like • Show 3 Likes3
Actions
S. Casale @ Lars Uhlenhaut on Mar 12, 2019 12:53 PM
Lars Uhlenhaut wrote:

Josh, I'm not one of those stupid users you mention. I have enough experience with SolidWorks to see if I have a bug or broken file in front of me.
If I send a file to the VAR that crashes three times in a row on the same action, I have a right that this issue is reported to SolidWorks and will not have to settle for a repaired file again. Especially since that does not solve the problem permanently. The simplest solution for the VAR. Instead, I get the repaired file with the comment "and now shut up". (not in these words, but analogously).
Usually I only send in errors once. Of course it may happen that after more than a year, I may report a mistake one more time, but only because due to the multitude of errors, I can no longer see that the error has occurred before. Furthermore, the error already should have been corrected by updates.
It can not be that users find "bugs" that are based on using the software. By "bugs" I understand crashes and misconduct of the software. If crashes occur due to incorrect operation of the software, then in my opinion the software has a bad error handling.
Furthermore, if I report an error, I do not know in advance if there is already an SPR for it. This research is the task of the VAR, we pay a lot of money for it. My job is to build machines, not to support software development. Nevertheless I spend a lot of time for this and don't see any cent for it.
I completely agree that it is not our job to troubleshoot software development.

As a user, the customer portal is helpful to the extent that one would hope that descriptions of SPR's would make sense all the time... and they don't...and, the Customer Portal is complete junk for navigating.

I can't say I know for a fact, but if an SR (not SPR) is generated for a problem, the VAR gets some sort of payment or something from SW. I would assume VAR's aren't working for free in the area of troubleshooting. If they are, well that's just silly.

I would find a different VAR.
Like • Show 3 Likes3
Actions
J. Mather @ Lars Uhlenhaut on Mar 12, 2019 1:03 PM
Lars Uhlenhaut wrote:

Since many of them are file specific, it is not practiable to send the files here.
Give it a try.
I enjoy the challenge of attempting to reproduce an issue.
Like • Show 2 Likes2
Actions
Arthur McRae @ Walter Fetsch on Mar 12, 2019 1:11 PM
VAR -> Supposedly stands for Value Added Re-seller.... If they aren't "Adding Value" find one that does.
Like • Show 6 Likes6
Actions
Tom Gagnon Mar 12, 2019 1:37 PM
If I had told my client,
We are told that we are by far the customer that costs the most time and effort.
, then my client would find someone else to perform their next project, even if it was valid and true. You can do the same when you re-subscribe next time. That will make your old VAR's life so much easier because they have one less paying customer. Win-win situation there.
[As an aside, do we have a thread for trash-talking horrible VAR's, as in: these people don't deserve your money? I believe that valuable feedback can prevent (us) others from providing them business and encountering substandard support for equal cost. We are Users, and we network.]

I knew a project manager that was fired for verbally telling a client on the phone, "every time you open your c*** sucker, this project is delayed two weeks." We finished that project well with others managing it through, but sure enough we never got more business from that client. I don't wonder why. At least your VAR didn't use profanity directly at you (or so I assume).

Is the person relating this nugget to you some tactless technical support rep, or a sales rep? There's a huge difference in the personality types that do those tasks. Take tactless comments with a grain of salt unless it comes from ownership or management. Judgement applies.
PS. My VAR rocks. I empathize.
Like • Show 4 Likes4
Actions
Ian McLean @ Glenn Schroeder on Mar 12, 2019 4:13 PM
Glenn Schroeder wrote:

Josh makes some excellent points. I've been using SW for 30+ hours per week for 10 years, and only report what I think are bugs to our VAR once or twice per year, and still probably 1/3 of those are something I've done wrong or didn't understand instead of bugs.
It probably depends on what functions you use in Solidworks. I only report bugs that are critical to my work and have no obvious work around. If I was to report all the bugs we come across it would almost be a full time job. Nearly all the problems we have reported are existing SPRs/become SPRs/ and /or are fixed in later versions of Solidworks. I can think off the top of my head of 1/2 a dozen bugs which have been in Solidworks for 5 - 10 years and still aren't fixed (in 2017 anyway). I simple can't be bothered going through the process of reporting them. I understand that Solidworks trying to filter problems to eliminate user error, but the time consuming process of VAR process puts many people off reporting minor bugs.
Like • Show 3 Likes3
Actions
Alex Taguchi @ Lars Uhlenhaut on Mar 12, 2019 5:35 PM
If you see an unusual amount of file specific issues, it's time to start looking at the root cause because file specific issues may not get reported to SOLIDWORKS by the VAR.

File specific issues usually need a very specific before and after example, showing the workflow that triggered the instability or error. If the VAR cannot reproduce the exact trigger, then SWX likely cannot either and they may do the same thing and simply delete/recreate the faulting feature and send it back "repaired."

If I were in your shoes, I'd start taking a look at it holistically and gather your own data to see if you can determine why you or your company are seeing so many file specific issues.

Make a shared google sheet and start tracking it internally:
- Who is seeing these issues?
- When are they occurring?
- What files are impacted?
- Where are these files being stored? Locally/server/cloud/PDM?
- Workflow before fault?
- Features impacted?
- What add-ins are in use on affected machines?
- OS and version of SWX in use for each machine impacted?
Also, it is fairly common to see file specific issues stem from ancient part/assembly/drawing templates. If you're not working with 2015 or newer file templates, then it's time to wipe out your old ones and start fresh with some new ones.

You maybe unfortunate and be running into a bunch of bugs, but in my experience there is something about that specific environment that's causing the frequent faults.
Like • Show 3 Likes3
Actions
Dennis Dohogne Mar 12, 2019 8:33 PM
Since you are able to reproduce the problem and are sending the file(s) and description to the VAR their very next action should be to reproduce the problem on their end. If they can reproduce it then they should be happy to pass it onto SWX and get you an SPR because now they can wash their hands of it and let SWX deal with it.

If the VAR can reproduce the problem and does not send it onto SWX then you need to ask them why? If it is a known problem in the Knowledge Base (though we have access to the KB the VARs are the ones it is really for and they should know how to navigate it better than we can) then that problem already has an SPR associated with it. The least the VAR can do at this point is to attach your name to the SPR. This does two things, it lets SWX know more people are having this problem and thus raises its priority, and it puts you on the list to be notified when the problem is solved.

If it is a recurring problem with an SPR then the VAR should be wise enough to realize that they can make you happy and get you off their back if they provide you with a work-around.

If your VAR is not doing those things then it seriously is worth considering making a change to one that will.
Like • Show 2 Likes2
Actions
Konstantinos Angelis Sep 2, 2020 8:26 AM
Greetings! We do use solidNOTworks 2020 (SP3.0) with the latest compatible GPU drivers installed etc.
The program is very slow and crashes more often than not even on new high end computers (laptops are also checked in the solidworks site in order to be compatible). SolidNOTworks is a shitty program! That is the plain and simple truth. Those &@&@ at SolidNOTworks corp should actually listen to customers complaints. Most VARs (not all of them) usually just take the money and leave you hanging. They do not bother helping you, despite them getting paid large sums of money for support.

I will look elsewere for a 3d CAD program.
Like • Show 5 Likes5
Actions
J. Mather @ Konstantinos Angelis on Sep 2, 2020 9:28 AM
Like the original OP you have not provided any actionable information?
Let's address your issues one-at-a-time.
So logical!
Start now...
Like • Show 2 Likes2
Actions
Konstantinos Angelis Sep 2, 2020 9:41 AM
You want proof right! There you go!
Laptop: Zbook G6 HP with Intel i7-9850H (32gb RAM) NVidia Quadro RTX3000 (latest compatible drivers installed).
Software SolidNOTworks 2020 (SP3.0)
Windows 10.
Solidworks ePDM

500pcs Assembly with only solidworks parts (not imported parts / parts with complex surfaces) loads in about 5min even when I am working offline on the PDM.

Program does not recognize surfaces when I select them after a while (usually 10min). I do have the assembly and 3 or 4 parts of it opened in tabs.

When the program crashes, it does after a while, the SldExitapp.exe crashes as well!
I try to contact the SolidNOTworks customer service and they just tell me to contact my reseller. The reseller does not do anything. At least AUTODESK has the courtesy of the actual company replying to the customer. When you pay top dollar to buy such expensive licenses, you should expect the provider to give you some attention.
Like • Show 4 Likes4
Actions
J. Mather @ Konstantinos Angelis on Sep 2, 2020 10:00 AM
You have not provided any actionable information.
Attach your assembly here (or provide drop-box link) to assembly that exhibits this behavior.

Who is your reseller? Name names.
Ask them to join this public discussion.
Like • Show 4 Likes4
Actions
Ben Nemec Sep 2, 2020 10:02 AM
I cannot help but throw my opinion in here concerning CAD issue reporting.
- to those of you that are implying "If you won't share your files/screen shots here then you must be just complaining about problems." Two letters come to mind: IP. I haven't used SW that long yet, but most of the issues stuff is similar to the other system I had used for some time and had many support issues in the other, some my fault, some were "reproducible issues." I would NEVER share a file or post a screen shot of an actual product related model in any public forum. The nature of what we do just simply forbids it. I ask you keep that in mind when you dismiss people that do not share their data. For many employees sharing actual product data in a public form is simply not an option, we don't do it.
- the previous CAD system didn't use VARs; support when directly to them. The people I talked to were incredible, I was usually ornery because I had a job to do and the tool wasn't working, but they were always patient and helpful. Furthermore they always encouraged calling in with issues, even if it was likely the same root issue but in a different file. Support doesn't fix the program, support doesn't decide what gets worked on, all they can do is forward when there is reproducible issues. Trust me, support wants known issues fixed too and the ones I've worked with want to help ease the pain in the mean time. So far my experience with our SW VAR is similar. Point is, it's their job to take customer complaints, their job, what they are paid to do.
- the previous point must be followed by this point and they cannot be separated. Be grateful. Unless they are undoubtedly blowing you off, assume they are doing their best to help and be thankful for that. It is their job to help you with issues, it's not their job to be a punching bag for something they are not in direct control of. Try to be nice, stereotypically we CAD user types are not real socially inclined, if you know what I mean. As I mentioned above, CAD is just a tool to me, it's not a toy it's not something I'm fascinated with, it's like a Fluke to an electrician or one of those awesome tire changing machines to a auto garage. I have a job to do and if the tool is not working I'm frustrated and by the time I take time to send a support request I'm grumpy. So, I have to try really hard to be nice and not shoot the messenger. I usually was only partially successful at that, so I'd try to apologize for being a jerk and tell them I know it's not their fault. We would understand that we were both dealing with a human on the other end of the line, each of us were just trying to do our jobs so we respected each other for that.
So if you your account manager at the VAR is telling you that you are a bad client and wants to get rid of you, maybe you should oblige them. If they are to the point of openly telling you that the relationship is probably not salvageable. If they were the problem you're onto a new VAR, fine. If you were the problem, well, I hope you learn to play nice before all of your bridges are burned. I don't know you so have no idea where the problem lies, just offering my perceptions and opinion; I do know that it's worth the effort invested in maintaining a healthy relationship with whomever is providing you with CAD support.

Best of luck.
Like • Show 6 Likes6
Actions
Konstantinos Angelis @ Ben Nemec on Sep 2, 2020 10:13 AM
Thank you Ben for your reply! Personally I do work under heavy pressure and the program has to be stable. I used to work with AutoDesk Inventor and SolidEdge and both these programs never failed me. I was forced to work with solidworks at my current job, so when I encounter problems (most of them PDM related) I tend to get cranky. It is my fault for letting my anger take control, but I really want to be honest here and just say that I do not enjoy working with solidworks.

Thank you again for your reply. I highly appreciate your time and insight.
Like • Show 3 Likes3
Actions

Reporting errors frowned upon?

Outcomes

Related Content

Recommended Content