Need some help to fix in foxpro does table a year

[Ernesto_Paez]

Hi everyone
i have two fields in the same table

one is named "Day", field type is date.
the other field is "sch_date", field type is date.

now i have a bunch of records where under the DAY FIELD and under the SCH_DATE i have the following as below


Day

SCH_DATE
12/19/1918 01/03/2000
01/03/1919 01/03/2000
01/09/1919 01/09/2000

so those under the DAY field for example 12/19/1918 should be 12/19/2018 and the one under SCH_DATE should be 01/03/2019 and not 01/03/2000
how can put to that the correct "year" ? this resides on a foxpro dos table
any help very appreciated
Thanks in advance

​

 

[Olaf Doschke]

With FOMONTH you can add 100 years = 100*12 months = 120 months. Or 19 years.

I remember such century errors in old VFP data, free tables, not DOS, but that data came a long way and once was DOS. So such faults can happen. Most likely with code not using centuries and then having the wrong rollover year you end up 100 years too early or too late. I also had data with century 0 or 100 or 200, though. The error of 2000 instead of 2019, truncating the year to just the century, that's new. I could imagine this comes from text data (CSV) and the year actually was meaning 2020, could you have data pointing to next year? Anyway, if that already sneaked into your data for longer than a year, 2000 could mean anything, also 2018 ir even 2017, it's hard to judge without further context.

It's good when you know the range of years data is allowed to be, then you can pull it into that range in 100 years steps for those cases you just have century errors, but I'd be very cautious to define 2000 always means 2019.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Ernesto_Paez]

Hi Olaf,
i will have to check the prg file that allows the data entry, in the field SCH_DATE, as well why the field DAY is getting erroneous date, because the date in DAY should be the date the employee login into a job, so that field "DAY" should be replace by today's date() but something is as you said the rollover could be wrong or "set cent to" it is wrong because if i login today, the DAY field should be 9/17/2019.

i don't know what date is today in your country today but the "SCH_DATE" it is imputed manually in data entry, before the user login into that record, so i believe, that they only enter for example 08/12 as the "sch_date" assuming that date the employee login into that record, then the code, should add the year to the rest in 08/12 but since we have the problem in Foxpro Dos about year 2000 or Y2K, maybe is interpreted year 2019 as 2000, so i need to do something to make sure at the point of the data entry to make sure the year is grabbed correctly.
Thanks

 

[Olaf Doschke]

You can't have century dates in Foxpro DOS? Id don't know, but I don't think so. The setting to display 4 digit year is SET CENTURY ON.

Set the initial value to DATE() and users can only edit it to another valid date, then this problem doesn't occur.

_screen.AddObject("daytextbox","textbox")
_screen.daytextbox.value = Date()
_screen.daytextbox.Visible =.t.

There are more comfortable entry methods with a calendar control. But as DATE() is the local system date, the users will then usually not need to change this at all.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[mjcmkrsr]

Hi,

The function is called GOMONTH()

? GOMONTH(DATE(),0) && today's date
? GOMONTH(DATE(),12) && today in 2020
? GOMONTH(DATE(),120) && today in 2029

The code below might give you some hints

USE yourtable
SCAN
[indent]REPLACE DAY WITH GOMONTH(DAY, 100 * 12), SCH_DATE WITH GOMONTH(SCH_DATE, 19 * 12)[/indent]
ENDSCAN

Please be aware that DAY() is also a VFP function and that it might be wise to rename this field name


@Olaf

100 years = 100*12 months = 120 months.

I still have an old HP calculator. Maybe I'll offer it to you as a XMas present

hth

MK

 

[Olaf Doschke]

You might of course work with @GET rather than a textbox control and I know less about that, but even when the input is just characters and you don't get a valid date from CTOD(userinput), you'd inform the user, go back in your workflow to the read of that date instead of just accepting an invalid date. A date in the year 2000 is technically valid, but when you know you expect today and perhaps allow a user to enter data about attendance times a few days back, you can still identify dates off by many years and demand a complete input or you can add the year yourself before using CTOD.

I can just look into what CTOD() results are in VFP9 and indeed VFP automatically adds the current year when it's missing or the century if you enter the two-digit year only. But I don't see glitches going back to 1st century or taking the day in an MDY date as the year and interpreting your MD entry as Month and Year or something like that. Eg if I put Foxpro in DMY mode and enter 9/18 that's invalid as there is no 18th month, but that doesn't make Foxpro interpret this as meaning September 2018. It just results in an empty date, which is something you should reject as input, too.

So this is more about validating input at the time it is made and ensuring you really get the date meant. An easy way to verify is to involve the user and simply reflect back how that input is turned into a date value by the code after the READ. Display the entered day and the user will see it's wrong. I don't know how hard it is to incorporate what is very easy in WinForms: Stepping back one or two controls by SHIFT+TAB. The only DOS PRGs I ever came across would have a rigid sequence you can only redo from start. Comparing to console applications doing a series of ReadLine() calls, which also don't allow you to go back.

But, of course, you shouldn't accept invalid data.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Hi MK, I see. But time flies, 100 years seem like 10. I remember the news about the confirmation of the west route to India really working out as if it was yesterday.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TamarGranor]

There were some issues with Y2K in FoxPro before VFP 5. I wrote about them back in 1999:

http://www.tomorrowssolutionsllc.com/Articles/FoxPro and Y2K.PDF

Here's my other article that's mentioned in that one:

http://www.tomorrowssolutionsllc.com/Articles/Legacy Apps and Year 2000.PDF

I don't know whether Christof's Y2K solution for legacy apps is available anywhere. (He's now Christof Wollenhaupt.) This might be it:

https://www.levelextreme.com/Home/ShowHeader?Activator=17&ID=9558

Also, not sure whether the Y2KFix program I mention in the second article is available any more.

Tamar

 

[mjcmkrsr]

Hi,

Depending on your VFP version you may also have a look at SET CENTURY and especially the ROLLOVER parameter (introduces in VFP 5)

hth

MarK