Y2K Question 
Author Message
 Y2K Question

Hello,

I need to convert a foxpro app to be Y2K complient.  Its currently
Fox 2.0, I thought about using the set century on command, but the
user don't like the idea of entering the century.

Has anyone looked at the option of adding windowing code to the
valid event of each entry date?  It looks like it works, but
I was wondering if there are any implications.

It looks like converting to VFP would be a major issue.

Thanks



Sun, 27 Aug 2000 03:00:00 GMT  
 Y2K Question

The option of putting code in the valid event will not work on 2/29/2000.
This happens because foxpro sees the entry "02/29/00" to be "02/29/1900" and the
year 1900 is not a leap year. Fox will not fire the valid in this case it
informs the user they have entered a invalid date and forces them to fix it.

The only way I know to fix this is to do date entry to a char field and in the
valid set the actual value into a date field.

I hope this was helpful.

Alan

Quote:

>Hello,

>I need to convert a foxpro app to be Y2K complient.  Its currently
>Fox 2.0, I thought about using the set century on command, but the
>user don't like the idea of entering the century.

>Has anyone looked at the option of adding windowing code to the
>valid event of each entry date?  It looks like it works, but
>I was wondering if there are any implications.

>It looks like converting to VFP would be a major issue.

>Thanks


Alan C. Sheffield
Developer
System Solvers Ltd.
248-588-7400


Sun, 27 Aug 2000 03:00:00 GMT  
 Y2K Question

Of course VFP is a major issue.  Just the fact that you still use 2.0
tells me your client is using a product that has been dead a long time.

Bit the bullet, and tell them.

Quote:

>Hello,

>I need to convert a foxpro app to be Y2K complient.  Its currently
>Fox 2.0, I thought about using the set century on command, but the
>user don't like the idea of entering the century.

>Has anyone looked at the option of adding windowing code to the
>valid event of each entry date?  It looks like it works, but
>I was wondering if there are any implications.

>It looks like converting to VFP would be a major issue.

>Thanks




Sun, 27 Aug 2000 03:00:00 GMT  
 Y2K Question

You could put in an Expression.  Ex:
VALID_DATE("S")  &&19,20/S

FUNCTION VALID_DATE
parameter century_type
date_var = varread()
do case
case century_type = "19"
    if year(&date_var) >= 2000
        &date_var = gomont(&date_var,-1200)
    endif
case century_type = "20"
    if year(&date_var) < 2000
        &date_var = gomont(&date_var,1200)
    endif
case century_type = "S"
    if year(date()) >= 2000 and year(&date_var) < 2000
        &date_var = gomont(&date_var,1200)
    endif
endcase
return .t.

For birthdays or any similar type days I'd recommend entering in a 4
digit year.  The above function can be used for order, invoice dates
etc.  Also, diisplay the 4 digit year ...but the ops can keep entering 2
digit years.

Quote:

> Hello,

> I need to convert a foxpro app to be Y2K complient.  Its currently
> Fox 2.0, I thought about using the set century on command, but the
> user don't like the idea of entering the century.

> Has anyone looked at the option of adding windowing code to the
> valid event of each entry date?  It looks like it works, but
> I was wondering if there are any implications.

> It looks like converting to VFP would be a major issue.

> Thanks




Sun, 27 Aug 2000 03:00:00 GMT  
 Y2K Question

ON READERROR will trap the 02/29/00 problem.  It fires when the user
types an invalid date.  I got this tidbit from the 3/98 issue of FoxPro
Advisor pg. 32.  Not sure if this is available in FP 2.0 though.

Quote:

> The option of putting code in the valid event will not work on 2/29/2000.
> This happens because foxpro sees the entry "02/29/00" to be "02/29/1900" and the
> year 1900 is not a leap year. Fox will not fire the valid in this case it
> informs the user they have entered a invalid date and forces them to fix it.

> The only way I know to fix this is to do date entry to a char field and in the
> valid set the actual value into a date field.

> I hope this was helpful.

> Alan


> >Hello,

> >I need to convert a foxpro app to be Y2K complient.  Its currently
> >Fox 2.0, I thought about using the set century on command, but the
> >user don't like the idea of entering the century.

> >Has anyone looked at the option of adding windowing code to the
> >valid event of each entry date?  It looks like it works, but
> >I was wondering if there are any implications.

> >It looks like converting to VFP would be a major issue.

> >Thanks

> Alan C. Sheffield
> Developer
> System Solvers Ltd.
> 248-588-7400



Mon, 28 Aug 2000 03:00:00 GMT  
 Y2K Question

Just for sake of argument.. how do people feel about continuing to
display/enter dates in 2-digit format?  What I mean is this:

Yes, in FoxPro you can develop schemes to interpret entered dates so that
00 is saved as 2000 and 99 is saved as 1999, etc.  But, I guess I came to
the conclusion that I would make my users see the dates in 4 digits and
enter them in 4 digits as well.  The reason for that being, it's a simple
solution and deep in my heart I believe that entering dates in 2 digits is
the root cause of all this potentially horrible fallout we are headed for,
and although it may sound presumptious, I'd like my users not to think in 4
digits for their own edification.  Of course, I'm not building systems
meant for intense data entry or anything like that.  Any opinions on this?



Quote:
> ON READERROR will trap the 02/29/00 problem.  It fires when the user
> types an invalid date.  I got this tidbit from the 3/98 issue of FoxPro
> Advisor pg. 32.  Not sure if this is available in FP 2.0 though.



Tue, 29 Aug 2000 03:00:00 GMT  
 Y2K Question

One of my client's Holy Grail is less keystrokes.  Before proceeding on new
apps we discuss keyboard entry.  His idea is less keystrokes is more
productivity.

When explaining the added keystorkes to dates and loss of productivity in
(overall) business to my mother (completely computer illiterate) she felt it
will help in adding/creating new jobs.

I'd hate to be a data entry person.  Some of them are heads down, pound data
fast and there will be some howls when programmers force 4 digit years.  I
guess it's the "if I add 10 minutes per day per person in DE with 50 end users"
you've just added a year's (lost) productivity with that 1 change.  You do that
in several other places in your apps  at your client site you can consider
yourself "helping the economy by putting people to work" as your business
clients needs to add manpower to do the work required.  Just don't let the boss
know what you are helping put "workers to work" at the cost to him/her in the
(tens of) thousands.

I agree that all year fields should display the century in DE.

Quote:

> Just for sake of argument.. how do people feel about continuing to
> display/enter dates in 2-digit format?  What I mean is this:

> Yes, in FoxPro you can develop schemes to interpret entered dates so that
> 00 is saved as 2000 and 99 is saved as 1999, etc.  But, I guess I came to
> the conclusion that I would make my users see the dates in 4 digits and
> enter them in 4 digits as well.  The reason for that being, it's a simple
> solution and deep in my heart I believe that entering dates in 2 digits is
> the root cause of all this potentially horrible fallout we are headed for,
> and although it may sound presumptious, I'd like my users not to think in 4
> digits for their own edification.  Of course, I'm not building systems
> meant for intense data entry or anything like that.  Any opinions on this?



Wed, 30 Aug 2000 03:00:00 GMT  
 Y2K Question

[Warning: slightly off-topic material as well as feeble attempts at
humor on my part follow.  Read at your own risk!]

: One of my client's Holy Grail is less keystrokes.

Data entry costs are often hundreds or thousands of times more than
software development costs.  No expense, whatsoever, should ever be
spared in making data entry as fast, accurate, and effortless as
possible in those kinds of apps.

: Before proceeding on new
: apps we discuss keyboard entry.  His idea is less keystrokes is more
: productivity.

All other things being equal, I certainly can't see why not!

: When explaining the added keystorkes to dates and loss of productivity in
: (overall) business to my mother (completely computer illiterate) she felt it
: will help in adding/creating new jobs.

The reality is just the opposite.  Waste and inefficiency are very
similar to theft in their impact on the economy.  They not only don't
create jobs; they destroy them.  The extra money an employer has to
pay as a result of inefficiency and waste does not magically appear
out of noplace.  It has to come from somewhere.  The common
misperception that underlies all this is that it comes from the
pockets of the employer.  That would not be a good thing even it were
true, for it prevents him or her from hiring as many people as would
otherwise be the case.  But it isn't true, in the long term, at least
with respect to publically-traded corporations.  There's a large,
global, and fairly liquid market for capital, and enterprises that
don't generate a competitive return on investment will be denied
capital and ultimately wither.  What really happens is that the added
costs are passed, in full, to the consumer.  The increased prices for
the goods or services in question take more money out of the
consumer's pocket that otherwise would have been spent purchasing
*other* goods and services that employ people in other industries.
Finally, in a competitive market (which markets that are
labor-intensive tend to be), those increased prices will drive the
firms that suffer them out of business completely unless the problem
is identified and corrected.

: I'd hate to be a data entry person.

I hate being a data entry person.  :)  Yes, I design, build, test,
implement, maintain, and upgrade relational database apps.  But where
do you think I get the sample data?  Has to come from somewhere, and I
have only one other person working with me.  She's part time, and I'm
a better typist than she is.  How about lookup tables?  I'd far rather
use a lookup table than complicated switch or DO CASE statements.  But
lookup tables don't grow on a tree in my front lawn that I can just
pick, de-bug (literally) and stuff into my application through the
floppy drive slot!  In my business, 99% of the time it's me who enters
them.

: Some of them are heads down, pound data
: fast and there will be some howls when programmers force 4 digit years.  I
: guess it's the "if I add 10 minutes per day per person in DE with 50 end users"
: you've just added a year's (lost) productivity with that 1 change.  You do that
: in several other places in your apps  at your client site you can consider
: yourself "helping the economy by putting people to work" as your business
: clients needs to add manpower to do the work required.  Just don't let the boss
: know what you are helping put "workers to work" at the cost to him/her in the
: (tens of) thousands.

It is his business to know and measure such things whether you tell
him or not!  Of course, I think that like most other things in life,
many people manage businesses based largely on emotion, not fact.  Why
else would nearly every U.S. business pay workers based on how much
time they spend on the job, rather than how fast or well they do it?

Now onto the main point:

: I agree that all year fields should display the century in DE.

I agree they should *display* all four digits but I do not necessarily
agree that the user ought to be forced to enter all four.  Frankly, I
try to make sure the user doesn't have to enter ANY digits if it isn't
necessary.  Sometimes it can default to the current year, or the same
year that the user entered in the previous record.  If a range of
dates that is much less than 100 years is expected, rollover rules may
make 2 digit DE suffice even though all 4 digits get correctly
populated as a result.

Good defaults, good business rules, and good common sense can save
lots and lots of money, and that *creates* jobs.

Joe Adams
Founder and lead developer
Quality Data Division of JTAE
http://junior.apk.net/~joe/QualityData.html



Wed, 30 Aug 2000 03:00:00 GMT  
 Y2K Question

Quote:
> deep in my heart I believe that entering dates in 2 digits is
> the root cause of all this potentially horrible fallout we are headed for,

Your heart is right; this idea of data entry productivity "demanding"
the entry of only two digits is foolhardy.  Consider:

An airplane wing requires 4,000 rivets.  The FatPig Airplane Corporation
can save by skipping every fourth rivet.  Save on rivets, save on labor,
save on wear and tear to the rivet machines.  We actually have to have
governmental agencies and lawsuit rights to (try to) prevent this
"savings" from happening.  If more people had heart, we would not have
the Year 2000 disaster, but since we don't, we will probably need a
"Year 2000 Safety Commission".  Do people never learn?

I do my own data entry, too.  Defaults do help.  If corporations are so
all-fired determined to get maximum productivity from their data entry
personnel, they should invest in voice recognition, rather than reducing
rivets below the design safety limit.  Four digits work, two digits
won't.  

Luthor



Thu, 31 Aug 2000 03:00:00 GMT  
 Y2K Question

What I wonder is, when we're REALLY going to start hearing about these
problems more and more, like on the news, etc.  It's like the thing we all
know is out there but it just won't come out into the light.  One would
think sooner or later the government WILL have to acknowledge it and take
actions, potentially drastic ones.  I've read that the IRS is not year-2000
compliant.  Sure, sounds great but it really is not.  I guess one thing
that whips me a little is wondering where the military stands in this
regard.

I agree here.  There is no reason why we can't display four digits in our
data and give the ability to change those first two digits (seeing that
that IS pretty much the problem).  I haven't done any projects involving
major DE.  Naturally, as programmers, we are trying to use sensible
defaults and keystroke-saving tricks to make our applications more useful
to our customers.  If your customer doesn't say, "Oh man that makes my job
easier" then we don't really feel like we've done it for them.

What's really sad is that over the years accomplishing that for users has
been a lot more like your analogy.  It gives me shudders when I'm at my
bank and watching the customer service agent type in MM/DD/YY when entering
data on my account.  I can't imagine that the data underneath is any
different, and I gotta wonder when the hell they are going to make the
change.  Especially banks, who forever have been putting profits above
maintenance and capital investment.  To please the stockholders, who really
aren't going to be so pleased pretty shortly.


Quote:
> "savings" from happening.  If more people had heart, we would not have
> the Year 2000 disaster, but since we don't, we will probably need a
> "Year 2000 Safety Commission".  Do people never learn?

> I do my own data entry, too.  Defaults do help.  If corporations are so
> all-fired determined to get maximum productivity from their data entry
> personnel, they should invest in voice recognition, rather than reducing
> rivets below the design safety limit.  Four digits work, two digits
> won't.  



Fri, 01 Sep 2000 03:00:00 GMT  
 Y2K Question

Quote:
>I do my own data entry, too.  Defaults do help.  If corporations are so
>all-fired determined to get maximum productivity from their data >entry

personnel, they should invest in voice recognition, rather than >reducing
rivets below the design safety limit.  Four digits work, two >digits won't.  

I dont get it.. why the fuss.. 2 digits work just fine.. I just retooled our
applications to accept two digits..first we exectue a YEAR(date) instruction.
If the year is before 1951 we execute a go month instruction to bump up the
date 100 years and this works just fine.. True that one leap year date could be
a problem..but its a minor one at best..  You'all can waste your time typing in
4 digits.. We are sticking to 2.

Michael Occhipinti
Automated Travel Solutions



Fri, 01 Sep 2000 03:00:00 GMT  
 Y2K Question

OK, so flame me for being ideological all of a sudden, but I believe that a
lot of what may be coming is due to this kind of thinking.  OK, no doubt
about it.. strike a balance.  Be practical.  If you have users who are
typing in date after date after date after date, it's pretty poor computing
to make them do a lot of extra work.  But honestly, I feel that everyone
being so conditioned to think of 2-digit this and that for years in dates
is exactly why not enough people do not understand Y2K and why all too many
people will not bother to use their heads when problems arise from it.

Don't ask me to prove this to you.  I can't and won't.  Watch and see what
develops in the next year or so.  I hope that it's all just a quiet
paranoia.

And if you've got the presence of mind to understand that years are really
4 digits long and not 2, even if their representation may be different,
then sure, tell us we are worrying about nothing.  I hope you can be just
as assured everyone you develop for has the same level of understanding.

I tend to think now the extra effort of pressing 2 more keys is less
costly.



Quote:
> I dont get it.. why the fuss.. 2 digits work just fine.. I just retooled
our
> applications to accept two digits..first we exectue a YEAR(date)
instruction.
> If the year is before 1951 we execute a go month instruction to bump up
the
> date 100 years and this works just fine.. True that one leap year date
could be
> a problem..but its a minor one at best..  You'all can waste your time
typing in
> 4 digits.. We are sticking to 2.



Fri, 01 Sep 2000 03:00:00 GMT  
 Y2K Question


Quote:
>OK, so flame me for being ideological all of a sudden, but I believe that a
>lot of what may be coming is due to this kind of thinking.  OK, no doubt
>about it.. strike a balance.  Be practical.  If you have users who are
>typing in date after date after date after date, it's pretty poor computing
>to make them do a lot of extra work.  But honestly, I feel that everyone
>being so conditioned to think of 2-digit this and that for years in dates
>is exactly why not enough people do not understand Y2K and why all too many
>people will not bother to use their heads when problems arise from it.

     Yes.

Quote:
>Don't ask me to prove this to you.  I can't and won't.  Watch and see what
>develops in the next year or so.  I hope that it's all just a quiet
>paranoia.

>And if you've got the presence of mind to understand that years are really
>4 digits long and not 2, even if their representation may be different,
>then sure, tell us we are worrying about nothing.  I hope you can be just
>as assured everyone you develop for has the same level of understanding.

>I tend to think now the extra effort of pressing 2 more keys is less
>costly.

     Certainly in development time, but if your system gets used
enough, the DE time adds up to more than was saved in the programming.
There is also the frustration factor for the operator.

[snipped previous]

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Sat, 02 Sep 2000 03:00:00 GMT  
 Y2K Question

Indeed - and if the client considers that a requirement of the product,
well then their wishes truly come first.  But now I'm not so wild about
doing it and take the extra time to make sure they understand why I feel
that way.



Quote:
>      Certainly in development time, but if your system gets used
> enough, the DE time adds up to more than was saved in the programming.
> There is also the frustration factor for the operator.



Sat, 02 Sep 2000 03:00:00 GMT  
 Y2K Question

I should also disclaim in that I have never worked on a project that was
used for huge amounts of DE (although starting on one soon), so I don't
have the point of view that many of you do on DE/keystrokes/what not.

Quote:


> >      Certainly in development time, but if your system gets used
> > enough, the DE time adds up to more than was saved in the programming.
> > There is also the frustration factor for the operator.



Sat, 02 Sep 2000 03:00:00 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Y2K Question

2. Another Y2K Question

3. Y2K Question: ON CURRENT event???

4. Foxpro 2.5 for DOS - Y2K and new PC questions

5. y2k fix for Fox 2.5,6

6. Foxpro Advisor Y2K Solution for 2.6

7. Y2K Conversion

8. Please HELP - Y2K

9. Y2K-compliance FPD2.5a

10. Help! Y2k compliant For FoxPro 2.5

11. Y2K: Requiring 4 digit date entry

12. Y2K Fix For Foxpro 2.x For Windows

 

 
Powered by phpBB® Forum Software