2000 compliance in Microsft Access 97 1

[RT]

I am currently trying to make an Acces 97 program 2000 compliant but I have come across a number of obstacles. <br>
1) The function DateAdd seems to be returning a 2 digit year date if the result is before 2000 and a 4 digit year date if the result is after 2000.<br>
2) Several queries reading from tables with 4 digit year dates are returning 2 digit year dates. This has not been consistent however as some queries are returning 4 digit year dates.<br>
3) A number of edit boxes whose source is a 4 digit year date field revert to 2 digit year dates on entry into the edit box.<br>
<br>
If anyone else has experienced similar problems I would really appreciate the info.<br>
<br>

 

[thrax]

Hey have you ever went to

http://www.microsoft.com/yk2000/

website<br>
maybe it has some useful info.

 

[trooper]

Have you tried doing a right-align parse in your query code. IIF the date code and grab the right two digits. Then the "19" or "20" on the left side won't be an issue.

 

[RT]

An interesting development has been that after leaving this problem alone for two weeks I came back to find none of these problems occurring any longer on my computer, but still occurring on a collegues. The only change has been that I installed the most recent version of foxpro so now I am trying to isolate exactly what has caused these problems to be rectified on my computer. <br>
<br>
Thanks for both your tips. The microsoft 2000 web site didn't seem to get down to a specific enough level to help. Our policy on 2000 compliance is to display all 4 digits at all times in programs so the right align parse won't do the trick. Also as it is a forecasting program it is neccessary to have the century information.

 

[databarn]

RT,<br>
<br>
Your last post kinda pointed at an answer, one that you seem to be investigating. May I suggest a tool or two for that investigation? <br>
<br>
ZDNet has a PCMag utility named InCtrl which is in its 3rd incarnation. It is a Delphi app that provides a couple of ways to take before and after snapshots of installs to Win95 (I think it'll work with NT desktop also, don't know about NT Server). It checks the registry, Win.ini and System.ini, as well as a limited number of other files that you may specify. It has proved invaluable in hunting down problems incurred by errant installs on my systems.<br>
<br>
If you have the Norton Utilities (Symantec), there is a registry tracker that works reasonably well, although it may hand you more data than you wish to review.<br>
<br>
Cleansweep for Win95 (Quarterdeck) is also a great tool for tracking system changes.<br>
<br>
Mind, all of these need to be present and running when an install is made, but the effort is insignificant compared to the troubles that can be traced.<br>

 

[JakeB]

Access stores dates internally as an 8 byte number which represents dates from the year 100 to the year 9999. So although you might not see all four digits of the year (such as a return value for the DateAdd function), Access is storing it internally. The trick is to display all four digits of the year so you know what Access is doing behind-the-scenes.<br>
<br>
For every table and form date field (and query field when appropriate) I do two things. First, I set for Format property to "mm/dd/yyyy" so that I (and the user) always see all four digits of the year. Second, I set the InputMask to "99/99/0099;0;_". This allows users to enter either a 2 or 4 digit year. However, since the format property is set as above, if a user enters only two digits for the year, the full year will automatically be displayed as soon as the user tabs off of the field.<br>
<br>
Good luck.

 

[databarn]

JakeB,<br>
<br>
Yep, you hit a head on the nail. But there may be a further problem here anent the Access interface to the Jet engine and other interfaces to the Jet engine (no intent to flame). One possible problem has to do with the Regional Settings applet in the Control Panel for Win95 (& NT?). <br>
<br>
A co-worker nigh went barmy over a date situation much like the one RT has described. What we finally ended up doing was a hodge-podge of updates, one or more of which apparently resolved the problem. The updates involved the TCP/IP stack (which should make no difference whatsoever) as well as some of the OLE components and reinstalling service releases for Office97. <br>
<br>
This seems far afield, but the bottom line was that regardless of the way Access handled dates internally, outward display of those dates was very much dependent upon a number of externals. Unfortunately, we never pinned down all the externals for the machines involved, we just 'shotgunned' them - expediency was the watchword in that particular instance.<br>
<br>
Naetheless, there's a laptop in my home system that shows such dates differently than its brother, and the only discernible difference between the machines is that one is a P233 processor and the other is a P266. Both were installed (Office97) from the same CD, both have had the same patches applied, both have _different_ installations of Visual Suite Enterprise edition, version 5. I'm in the [groaningly slow] process right now of trying to identify version differences of the files on each machine to try to pin this down. Since we're pretty close to the regional MS office, the techs there looked, but couldn't pin anything down (wouldn't let them reload _anything!_).<br>
<br>
Don't mean to be critical here, nor to flame your post. Just pointing out that there are a few vagaries left to be explored. (But, why does my boss make _me_ the Vasco de Gama, the Cortez, the Lewis and Clark when such things as this start shaking Humpty Dumpty's wall &lt;whine!&gt;?)<br>
<br>
Make a good day . . .<br>
. . . barn<br>

 

[JRumage]

Access 95 & 97 both use the OLE Automation library to determine what rules to apply to dates. So any software you install that updates or changes this library will affect how access handles dates. <br>
<br>
I suggest (If you haven't already) that you read the following article:<br>
<br>
Access, VB, Office, and the Year 2000<br>
<br>
You can find it at

http://www.fmsinc.com/tpapers/year2000/index.html<br>

 

[JakeB]

I think databarn accurately points out the subtlety of the Y2K issue. Since a single piece of software relies so heavily on a vast number of other pieces of software (such as the OLE Automation library and network libraries), it is often difficult to track down and predict problems like what will happen on 01/01/00. Databarn brings forth a good point: making sure that the code you write is Y2K-ready is only a small portion of the task. The hard part is getting down and dirty with everything else your code relies on. So journey forth Columbus!<br>
<br>
JRumage - Thanks for the article suggestion.<br>