Peter, It's been a while since I worked with Crystal reports (Ver 9 no less) but I remember a "Use Labels" check box on the login dialog when you connect to the ARsystem via the ARODBC connection on your PC. Was that for field Labels?
John J. Reiser Senior Software Development Analyst Remedy Administrator/Developer Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A. Sent: Thursday, October 16, 2008 8:32 AM To: arslist@ARSLIST.ORG Subject: Re: What's a bug anyway? (Kind of a rant...) ** Its transparent for the ones writing a simple AR System report from Tools / Reporting but for the ones writing Crystal Reports they see the database names and not the field labels. Thanks Peter Lammey ESPN IT Client Architecture and Automation 860-766-4761 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn Sent: Wednesday, October 15, 2008 5:22 PM To: arslist@ARSLIST.ORG Subject: Re: What's a bug anyway? (Kind of a rant...) ** Actually, that's one of my favorite examples of inconsistency in ITSM. I don't think it's because the same person created all of those fields, I think it suffers the same problems any other large, long-lasting ARS application does. So to further your complaint, the Change Manager's database name is "CAB Manager ( Change Co-ord )" The Change Assignee's database name is "ASCHG" The Change Implementer's database name is "ChgImp" You have all different naming conventions used for each set of fields, and it gets even worse when you talk about company information for those too. The Change Manager's company is called "Company3", not to be confused with "Support Company" that somehow references the Requester (which may not even be a part of any support group) and I'm not aware of a Company2 field. On the bright side, it keeps us employed, and those names are mostly transparent to the end users. Just don't let them have SQL access to the database... Shawn Pierson From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A. Sent: Wednesday, October 15, 2008 3:55 PM To: arslist@ARSLIST.ORG Subject: Re: What's a bug anyway? (Kind of a rant...) ** The naming conventions used for many of the fields on the various ITSM forms is terrible from what I have seen. The worst is the CHG:Infrastructure Change form where there are fields such as ASCHG, ASLOGID, ASGRP. The developers for these applications really should have been more privy to better naming standards and better naming conventions than that. I have been constantly having to assist users that are trying to writeup Crystal Reports and other ad hoc Remedy AR System reports on what fields to add to their report or as part of their Report criteria who struggle with figuring out what fields they would need. Thanks Peter Lammey ESPN IT Client Architecture and Automation 860-766-4761 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W Sent: Wednesday, October 15, 2008 4:43 PM To: arslist@ARSLIST.ORG Subject: Re: What's a bug anyway? (Kind of a rant...) ** If it is a Join form I think the fields should be renamed WorkLog Submitter, Incident Submitter, WorkLog Create Date, Incident Create Date, ... Not having the ITSM app I couldn't tell you if that would break anything, but that approach is our normal design for Join Forms here Fred ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Wheeler, Dylan Sent: Wednesday, October 15, 2008 3:29 PM To: arslist@ARSLIST.ORG Subject: Re: What's a bug anyway? (Kind of a rant...) I could think of a few instances where you would want to have all those fields though. You want to see who submitted a incident as well as who submitted the worklog. When the incident was created in the same report as when the worklog entry was submitted. Granted, it could be presented in a lot better fashion :) Why not create a defined report for them to run? I know it doesn't fix the problem but it's a workaround for now. As to your problem, like you said, you are the advocate for your client. I would report it even though you know they'll come back with either "Works as designed" or a bug report number that probably wont get fixed for 5 years since it's not a critical bug. You are not a BMC employee so it's not on you to get it fixed. Once you report it and get the feedback to give to your client your role is fulfilled. Alternatively, you could compile a list of the problems and present them to your client. I've worked for clients that were down to earth and as long as you have a workaround that lets them do what they need to do they don't sweat the small stuff. Anything that doesn't have a workaround and that they don't blow off as not effecting their job you report. That's my 2 cents anyway. ------------- Dylan Wheeler Production Control Analyst Principal IT Operations Downey Savings & Loan Association, F.A. Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: Wednesday, October 15, 2008 1:11 PM To: arslist@ARSLIST.ORG Subject: What's a bug anyway? (Kind of a rant...) I'm torn whether or not to report some things to BMC as bugs. For example, in IM 7.x the form HPD:Search-Worklog is an OOB join form that is used in the "Advanced Search" functionality from the Incident Nav Bar (when you are in an actual Incident). This allows you to search a join form of Work Log entries + Incident Info. Here's the problem - if you are on the Mid-tier and do a search and then select multiple results list items and choose the "Report" button you get dumped to the standard (ad hoc) report console for the web. The field selection list in there shows all fields from the Join form (including those not displayed in any of the views). That gives us multiple entries for fields like Submitter, Submit Date, etc etc etc (all the usual suspects). Knowing how Remedy works I'd expect this - but I still would call it a bug. It's definitnly an interface design error. However, if I reported every instance of this in the application I suspect it would run in to the hundreds of occurrences. On the other hand I'm pretty much obligated to report it as a bug since I am advocating for my customer and this makes the report interface unusable. They do not know which field to use in the report. Since they are interested on reporting on all Work Log entries for a particular problem, including the submitter and the Work Log Submit Date they legitimately can not tell which is which. And since they only have web access they can't exactly go check other than through trial and error. What do YOU do with this sort of problem? William Rentfrow Principal Consultant, StrataCom Inc. [EMAIL PROTECTED] 701-306-6157 C __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ________________________________ Please consider the environment before printing this e-mail. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ Private and confidential as detailed here <http://www.sug.com/disclaimers/default.htm#Mail> . If you cannot access hyperlink, please e-mail sender. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
