What kind of errors are you having in form definition change?

The reason I am asking is that we are running MT 7.1 Patch 3 here, and we do 
have problems sometimes when a new column is added to a table field (null 
pointer assignment). I cannot say for certain if this happens on additions of 
other fields too as I am yet to determine all the reasons why I get that error. 
This error goes away after manually flushing the cache.

Also I have reasons to believe that if you have persistent cache turned on, and 
if in case you do restart the web server daemon, the object invalidation 
counter probably gets reset? I noticed on one of our forms, the changes to the 
definition weren't yet caught by the mid tier way after the invalidation 
interval, and the only reason I can think of is that this counter gets reset 
everytime the web server daemon is restarted.

Is your problem something similar?

Joe


----- Original Message ----
From: strauss <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, October 7, 2008 3:33:57 PM
Subject: Re: Another Issue with 7.1 Mid-Tier Patch 3/4

**  
Do you know if it has been fixed in the soon-to-be-released
patch 005???  I’m waiting on that to solve a problem with form
definition change errors.
 
Christopher
Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From:Action Request
System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Perrault
Sent: Tuesday, October 07, 2008 12:01 PM
To: [email protected]
Subject: Another Issue with 7.1 Mid-Tier Patch 3/4
 
** 
All,
Got
another issue with the 7.1 Mid-Tier Patch 3 and Patch 4.
Have
Created an Issue with BMC: ISS03343227
Will
let you know when I have a defect ID and what that Defect ID is.
 
MS
Server 2003
IIS
6 (I think)
Apache/Tomcat
Mid-Tier
7.1 Patch 3 (and tested with Patch 4).
 
It
appears there is a problem with how ViewFormServlet handles the User Time Zone
and passed in Field Parameters.
 
Here’s
the situation:
We
send emails from our system. In those Emails we include a URL.
This
URL includes parameters for the Incident #, Server, Mid-Tier, View, UserName,
Password and some other field values.
Well,
the first time that a person clicks on the link, it appears that
ViewFormServlet is wiping out all the passed field parameters with this: 
usertimezone=America%2FChicago.
Well,
the second time the user clicks on the link it all works fine and brings up the
incident without issue.
So,
Hazarding a guess, it looks like the first time, it tries to find the
User’s TimeZone in the cache based on the URL that was supplied,
Doesn’t
find it and slaps that over the top of the other parameters, then Caches the
Timezone.
Next
Time the person clicks on the link, it pulls the timezone out of the cache and
works correctly.
 
For
example:
You
give the URL:
http://MID_TIER_SERVER/arsys/servlet/ViewFormServlet?form=FORM_X&view=VIEW_X&server=AR_SERVER&username=Bozo&pwd=TheClown&F1000000868=00001&F2020000916=XXXX&F1990001=IncidentEmail&?mode=Query
 
It
will translate into the following URL:
http://MID_TIER_SERVER/arsys/forms/AR_SERVER/FORM_X/VIEW_X/?usertimezone=America%2FChicago&cacheid=25255df7
 
Then
if you click on the link a second time it works.
Also,
If
you pass the usertimezone parameter in on the first URL it will also work fine.
The
problem with that is now you are hardcoding a specific timezone into the URL.
That
won’t work for us as we could have a person in the US, sending this link
to some one in India and it needs to pick up that person’s local
timezone.
 
Bottom
Line ViewFormServlet is not picking up the TimeZone from the user’s PC
and handling it correctly.
 
Thanks,
Matthew
Perrault




_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to