RE: st: problem with latest update?

["Visintainer, Paul" <Paul.Visintainer@baystatehealth.org>]

Thanks, Alan, for the explanation.  (It's not surprising that the problem may be at my institution).  I'll forward your explanation to our IT department.  This is the first time in several years (and dozens of updates) that the issue arose.  Hopefully, we just caught them between cache purges.  

-p

________________________________________________
Paul F. Visintainer, PhD



**********************

Others suggested to Paul that he should force another update, which
he can do with the commands

    . update executable, force
    . update utilities, force
    . update ado, force
    . update swap

Paul reported that this resolved the problem.  He also reported
that this same problem had arisen with several machines at his
workplace, and that even though his machine now has the 30 Mar 2011
Stata executable on it, -update- is still showing the latest
available update is 04 Nov 2010.

There is nothing to worry about here; everything is fine with
both Stata and with the update for Stata on www.stata.com.

The problem Paul is seeing is caused by a caching proxy server or
firewall at his organization improperly caching an 'update' file
from www.stata.com which contains the old update date of "04 Nov 2010"
rather than retrieving the latest version of the 'udpate' file from
www.stata.com which contains the new "30 Mar 2011" date in it.

The file is literally named 'update' and literally has the text
string '30 Mar 2011' in it.  Stata reads this file over the Internet,
compares it to the date of itself, and determines from that whether
an update needs to be performed.

If a caching proxy server holds on to an old version of that file
and gives the old version to Stata when Stata tries to download it,
Stata can't see that there is a new update available.  The 'force'
workaround shows above will work so long as the proxy server does
not also cache the executables or ado-files.

Usually proxy servers which have cached such files will flush their
caches on a regular basis, either daily or weekly, so such a problem
would typically resolve itself within a short period of time.


--Alan
ariley@stata.com

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

----------------------------------------------------------------------
Please view our annual report at http://baystatehealth.org/annualreport
 

CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please reply to the sender immediately or by telephone at 413-794-0000 and destroy all copies of this communication and any attachments. For further information regarding Baystate Health's privacy policy, please visit our Internet site at http://baystatehealth.org.

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/