date problem.

[Jay Ashworth]

----- Original Message -----
> From: "Richard Kreiss" <rkreiss at verizon.net>

> In answer to your reply, the date fields are (10,mdyy/). The issue is that
> when pfcmark is set to 20, and the operator type in an expiration date of
> 031520, filepro expands the date to 03/15/1920. This would be fine for a
> birthday but not an expiration date of 03/05/2020. I have changed it to
> pfcmark="30" to accommodate the expiration dates

This isn't a code problem, or a PFCMARK problem.  It's a user problem.

> Since my client has members who are over 70 years old and deal with credit
> cards which expire in 2020 or later, the setting of pfcmark creates a
> problem.

Unset it.  I believe that if it's empty, those entry attempts will simply
fail.

Users might not be happy about having to enter 4 digit years, but that's a
separate issue, outside filePro's scope.  :-)

> At this point my client is having the birthday information entered with all
> 10 characters as he doesn't want to pay for two easy solutions to the
> problem.

Oh.  They're *already* using the proper solution.  

Got it.  :-)

> Since most of the member information is imported, I could set pfcmark=20 for
> the import routines which would insure the proper birthday values. The some
> simple programming san be added to insure, if the date is changed, it still
> falls in the proper date range.

Well, you hadn't *said* "import" til now.

> This is an issue that insurance companies most have as they have clients who
> were born prior to 1930 and have policies which are paid automatically to a
> credit card when the premium is due. They need to be able to handle this
> date problem also

Well, if it's an import, you still shouldn't be depending on PFCMARK; 
you should convert it manually, so you can lean one way on birthdates,
and the other way on CC expires.

> As an aside, in 1992 I had already built in date programming to handle Y2K
> problem. This was many years before filePro add pfcmark which basically
> built in what my programming was doing. One client is still using that
> programming. 

Good to know.

I have some code that old still in production myself.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274