Hello Mark, Our ticket number is ISS03085228. If you would like I could sent you the detail off-list.
Thanks, Dave Davis David J. Davis SAIC Senior Software Systems Engineer Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter Code 0552, Bldg. 3173 300 Highway 361 Crane, IN 47522-5001 Ph: 812.854.2150 DSN: 482-2150 Fax: 812.854.3385 Email: [EMAIL PROTECTED] -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Whilden, Mark D. Sent: Tuesday, April 03, 2007 21:37 To: [email protected] Subject: Re: ARS Report Creator's time problem on queries Kelly and Dave, Our server admins decided to setup our servers in GMT. We think it is because they wouldn't have to worry about day light savings time bugs, but that is just our conjecture. We did a test today and when the server was switched to EST (the time zone our users are in), then we think the problem went away (still being tested). Dave, can you send us the BMC bug number that you are working under. We are talking to BMC also and this would help them consolidate their efforts. Maybe the fact that several of us have the same problem, will convince BMC to fix the problem in 6.3 instead of recommending upgrading (their usual line). Mark Whilden MITRE Corp -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 Sent: Tuesday, April 03, 2007 3:18 PM To: [email protected] Subject: Re: ARS Report Creator's time problem on queries Hello Mark and Kelly, We are experiencing the same problem with our installation of Remedy ARS 6.3 running MidTeir 6.3. Our database is SQL2000. The only difference is that we are showing a 5 hour discrepancy. This is explainable due to the fact that our Remedy server is running in the Central Standard Time. We have a BMC Support ticket on this problem and BMC Support stated it was unlikely that it would be fixed in Version 6.3 and suggested that we upgrade to MidTier 7.0.1. As you mentioned before, this problem only effects users running reports from the MidTier that are in different time zones (e.g. User in EST while server is in CST). What time zones are your users and MidTier in? Our problem occurs while our users are in EST and our MidTier is in CST. Thank You for Your Posting, Dave Davis -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Heikkila Sent: Tuesday, April 03, 2007 11:33 To: [email protected] Subject: Re: ARS Report Creator's time problem on queries We have the same issue when running reports. This started happening at a client site after the time zone patch was installed (we believe--or agents were paying more attention, as you mentioned). This has not yet been resolved that I am aware of. ARS 6.3 Oracle Kelly Heikkila Kinetic Data -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 10:42 AM To: [email protected] Cc: Whilden, Mark D. Subject: ARS Report Creator's time problem on queries Listers, After we applied the Daylight Saving time patches, we started to pay more attention to time zone issues. Note, I don't think the DST patch caused this, but caused us to look into time fields more closely. We found that for report run from Report Creator form, any queries against date fields weren't adjusted for difference between our zone (EST) and GMT. The Report Creator form is used for running Crystal Reports within ARS, or running ARS reports and Crystal Reports thru the MidTier. Whither we ran Crystal Reports or ARS reports from the web, or Crystal Reports from the client; we got the same results. If I ran the same query in User tool the query ran correctly. All the tools display the dates correctly in the reports or on the forms. To investigate this, I turned on SQL logging and repeated the same queries from the Report Creator and from User search. The Select statements vary within the where clause in the constant used against the date column. The difference is 14400 seconds or 4 hours. That is the difference between us and GMT. Our systems people are looking into time zone on the server, but I am doubtful this is the problem. However, I don't have a good culprit to pursue. Anyone seen this before or have a clue as to where to look to resolve this. Mark Whilden MITRE Corp [EMAIL PROTECTED] (571)252-4023 _______________________________________________________________________ _ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________ _ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________ ________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
BEGIN:VCARD VERSION:2.1 N:Davis;David FN:Davis, David CTR NAVSURFWARCENDIV Crane, Code 0552 ORG:USN Contractor;SAIC TITLE:CONT TEL;WORK;VOICE:(812) 854-2150 TEL;HOME;VOICE:(812) 847-7204 TEL;CELL;VOICE:(812) 384-6456 ADR;WORK:;Bld 3173, Code 0552;300 Highway 361;Crane;IN;47522-5000;UNITED STATES LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Bld 3173, Code 0552=0D=0A300 Highway 361=0D=0ACrane, IN 47522-5000=0D=0AUNIT= ED STATES EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20061011T155306Z END:VCARD
