Not a problem, Tony. I never want someone to just blindly accept a quick fix. It would be great if manufacturer's would commit the kind of resources you mention when I submit an intermittent/can't replicate/seems to only be on my system type of problem, but my experience is with this kind of one-off, small potato client's problem, I'm lucky if I get a first-tier, new to their helpline, fresh out of training rookie to even give me a call to verify if I knew what I was saying.
To me, a work-around is far more desirable to try and gather more information in the error reporting than to leave the situation as is with nothing to give back to the system owner besides a shoulder shrug. If the problem changes, this is as good a piece of information as any that it's most likely not data related and that the problem really does need the type of resources you mentioned. As always, Tony, you have very good, valid information that you generously share with everyone. We all appreciate that of you. BobW -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Friday, July 26, 2013 10:13 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing > From: Woodward, Bob > If this occasional problem is consistently the same lines then just > validate the insert afterwards... Dale, don't accept that solution. (Sorry Bob) Note, we're still not really Sure yet that this is a good definition of the problem, just a working theory... Overall, the problem seems to be that some statements can't be trusted to be executed - not specific statements or functions, but random lines of code in different systems. The problem might not be something wrong with the statements themselves but just where they happen to be in the program. The issues might be fixed with some extra code, or by putting the few lines in question into an internal subroutine just to move the bytecode to a different location. But a "solution" like that is random and subject to just moving the problem to an as yet unknown and perhaps more critical location. When you can't trust a line of code to be executed in a linear series of statements the reliability of everything we do comes into question. If this is indeed the problem, "fixing" it by writing work around code isn't good for anyone here. It's tough to call in Support when the problem is so vaguely defined but having "sat in the chair" as a QA Manager and Product Manager for a related product, I can tell you the resolution starts with finding sites that seem to have this issue, assigning someone to the task of gathering data and scheduling tests on the target systems, getting engineers to verify the issue, and establishing a pattern from which a problem can be diagnosed. I don't know who has to initiate that with Rocket Software but I'd assume it starts with paying clients filing formal requests with Support and committing to follow-through toward a resolution. And while re-compilation might indeed be the correct fix, don't accept a tier-1 techie solution intended to just get you off the phone! HTH T _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
