Y2K-compliance FPD2.5a 
Author Message
 Y2K-compliance FPD2.5a

I was wondering where I could find the Y2K-compliance for FPD2.5a. Microsoft
doesn't say a word about this version. Are there any problems we could
expect with this version, except for the usual 4-digit year in/output?

Thanks for any reaction
Hans Walrave



Sat, 27 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
Hans,
Go to
http://www.microsoft.com/technet/year2k/product/user_list.asp?prod=1454. I
believe everything stated for 2.6 also applies to 2.5 - dates and date
handling didn't change between these versions.

Rick


Quote:
> I was wondering where I could find the Y2K-compliance for FPD2.5a.
Microsoft
> doesn't say a word about this version. Are there any problems we could
> expect with this version, except for the usual 4-digit year in/output?

> Thanks for any reaction
> Hans Walrave



Sat, 27 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a

Quote:
> I was wondering where I could find the Y2K-compliance for FPD2.5a. Microsoft
> doesn't say a word about this version. Are there any problems we could
> expect with this version, except for the usual 4-digit year in/output?

I expect it is the same as FPD2.6a. And that one is available on the
Microsoft site. The problem that two numbers for the year always become a
year in 19xx, can be solved with Y2KFOX. Look for it on
www.hallogram.com.
--
Groetjes,
   Wim de Lange


Mon, 29 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
Just make sure you have removed all
references to DTOC() and CTOD()
and make sure the user has his windows
control panel settings set to 'Long
Date'
If you try to run your application on an
NT machine, you will start getting
'16-Bit' error messages.
Also make sure you have the patch
applied if you run your app on a 300MHZ
or faster machine.
Windows 2000 probably will not allow
your app to run at all.
Quote:


> > I was wondering where I could find the Y2K-compliance for FPD2.5a. Microsoft
> > doesn't say a word about this version. Are there any problems we could
> > expect with this version, except for the usual 4-digit year in/output?

> I expect it is the same as FPD2.6a. And that one is available on the
> Microsoft site. The problem that two numbers for the year always become a
> year in 19xx, can be solved with Y2KFOX. Look for it on
> www.hallogram.com.
> --
> Groetjes,
>    Wim de Lange



Mon, 29 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
Does FP2.5/6 care about your Windows data settings at all?
In negative test reports on Windows 2000 and FP2 applications yet?
-Anders


| Just make sure you have removed all
| references to DTOC() and CTOD()
| and make sure the user has his windows
| control panel settings set to 'Long
| Date'
| If you try to run your application on an
| NT machine, you will start getting
| '16-Bit' error messages.
| Also make sure you have the patch
| applied if you run your app on a 300MHZ
| or faster machine.
| Windows 2000 probably will not allow
| your app to run at all.
|

| >

| >
| > > I was wondering where I could find the Y2K-compliance for FPD2.5a.
Microsoft
| > > doesn't say a word about this version. Are there any problems we could
| > > expect with this version, except for the usual 4-digit year in/output?
| >
| > I expect it is the same as FPD2.6a. And that one is available on the
| > Microsoft site. The problem that two numbers for the year always become
a
| > year in 19xx, can be solved with Y2KFOX. Look for it on
| > www.hallogram.com.
| > --
| > Groetjes,
| >    Wim de Lange



Tue, 30 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
I have tested my Foxprow2.5 as well as I can for Y2K compliance and can
find no problems after setting Century ON which displays a 4 digit year.
I have made myear=CTOD('31/01/1999') and incremented one or more days
and tested whether all parts of the date are correct, and done the same
for 28/02/2000 for Leap Year. No problems with CDOW(), DTOC(), CTOD() or
other date functions. My computer is new running WINDOWS 98 and is
itself Y2K compatible.

Have I missed something ? If not, where is the problem ?



Quote:
>Does FP2.5/6 care about your Windows data settings at all?
>In negative test reports on Windows 2000 and FP2 applications yet?
>-Anders



>| Just make sure you have removed all
>| references to DTOC() and CTOD()
>| and make sure the user has his windows
>| control panel settings set to 'Long
>| Date'
>| If you try to run your application on an
>| NT machine, you will start getting
>| '16-Bit' error messages.
>| Also make sure you have the patch
>| applied if you run your app on a 300MHZ
>| or faster machine.
>| Windows 2000 probably will not allow
>| your app to run at all.
>|

>| >

>| >
>| > > I was wondering where I could find the Y2K-compliance for FPD2.5a.
>Microsoft
>| > > doesn't say a word about this version. Are there any problems we could
>| > > expect with this version, except for the usual 4-digit year in/output?
>| >
>| > I expect it is the same as FPD2.6a. And that one is available on the
>| > Microsoft site. The problem that two numbers for the year always become
>a
>| > year in 19xx, can be solved with Y2KFOX. Look for it on
>| > www.hallogram.com.
>| > --
>| > Groetjes,
>| >    Wim de Lange

--
Tim Hobson


Tue, 30 Apr 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
If you have a date entry field on a screen, try entering a 6-digit date (which
foxpro allows you to do, even when you have set century on).  The date will
always come up with a year of 19nn.  There is no way to force the user to enter a
four-digit year, except to process the date entry as a string, and check the
length yourself.  This is what I have done in fpw 2.6a applications that have to
live beyond 1jan2000...

The problems with ctod() happen when you transfer your software to a machine
where the user has their windows control panel set differently than the machine
you developed on...  See what happens when you change your windows date control
panel from British date format to American...

As far as I know, foxpro 2.5/2.6 handles the dates properly once they are entered
into the database, and date arithmetic all seems to work properly, as do the date
functions year(), month(), day(), dow(), etc.  The serious problems happen when
you try to do date manipulations with the components of a date, and then put it
all back together with ctod().  I had a fpw 2.6 application that allowed the
input of multiple date ranges by dragging across a calendar which was displayed
on screen, and it went berserk when I carried it from the US to Australia.  For
date format independence and for Y2K, I had to completely redo all my code to
generate the dates as relative offsets to a fixed date, rather than building them
from strings based on mouse positions.

I haven't had any problems running on NT machines, as long as the foxpro patch
for machines faster than 300 mz has been applied...  We have had a number of NT
4.0 machines running a fpw 2.6 database, and exercising it heavily, for about a
year now...

-- David Shields

Quote:

> I have tested my Foxprow2.5 as well as I can for Y2K compliance and can
> find no problems after setting Century ON which displays a 4 digit year.
> I have made myear=CTOD('31/01/1999') and incremented one or more days
> and tested whether all parts of the date are correct, and done the same
> for 28/02/2000 for Leap Year. No problems with CDOW(), DTOC(), CTOD() or
> other date functions. My computer is new running WINDOWS 98 and is
> itself Y2K compatible.

> Have I missed something ? If not, where is the problem ?



> >Does FP2.5/6 care about your Windows data settings at all?
> >In negative test reports on Windows 2000 and FP2 applications yet?
> >-Anders



> >| Just make sure you have removed all
> >| references to DTOC() and CTOD()
> >| and make sure the user has his windows
> >| control panel settings set to 'Long
> >| Date'
> >| If you try to run your application on an
> >| NT machine, you will start getting
> >| '16-Bit' error messages.
> >| Also make sure you have the patch
> >| applied if you run your app on a 300MHZ
> >| or faster machine.
> >| Windows 2000 probably will not allow
> >| your app to run at all.
> >|

> >| >

> >| >
> >| > > I was wondering where I could find the Y2K-compliance for FPD2.5a.
> >Microsoft
> >| > > doesn't say a word about this version. Are there any problems we could
> >| > > expect with this version, except for the usual 4-digit year in/output?
> >| >
> >| > I expect it is the same as FPD2.6a. And that one is available on the
> >| > Microsoft site. The problem that two numbers for the year always become
> >a
> >| > year in 19xx, can be solved with Y2KFOX. Look for it on
> >| > www.hallogram.com.
> >| > --
> >| > Groetjes,
> >| >    Wim de Lange

> --
> Tim Hobson

--
Arisbe Information Systems, Inc.
http://www.arisbe.com


Fri, 03 May 2002 03:00:00 GMT  
 Y2K-compliance FPD2.5a
Di David,

Quote:
>There is no way to force the user to enter a  four-digit year, except to

process the date entry as a string, and check the length yourself.

Y2KFOX works in this situation and applies a rollover. My Y2K solution would
perform a rollover, as well, but does with any date entered, not just
a2-digit years.

Quote:
> The problems with ctod() happen when you transfer your software to a
machine
> where the user has their windows control panel set differently than the
machine
> you developed on...  See what happens when you change your windows date
control
> panel from British date format to American...

Nope. The Windows setting shouldn't affect the SET DATE setting in FP2.x,
it's only in VFP with SET SYSFORMAT ON.

Christof



Tue, 14 May 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. foxpro application Y2K compliance

2. Y2K Compliance

3. Y2K Compliance of VFP 5.0

4. FoxPro 2.5 Y2K compliance

5. FPW2.6 and Y2K Compliance

6. Y2k Compliance

7. Curious mouse problem while running FPD2.5a under Win3.1

8. Currupt dbfs Novell 4.11/FPD2.5a

9. FPD2.6 Y2K (LEAPYEAR FEB 29/2000) PROBLEM

10. FPD2.6 1 Y2K

11. List Box for FPD2.5 or FPD2.6

12. Year 2000 Compliance

 

 
Powered by phpBB® Forum Software