Y2k issue 
Author Message
 Y2k issue

In one of my applications written in clipper, it selects data >= to the
current date minus 30 days.  Since the year 2000 has hit the scene, no
records with the year 2000 are selected and shown on the screen when
the application is executed.

So far I have updated the DBU.EXE with set epoch to 1980 and set
century. Because of this when I execute the DBU utility I see dates in
the database in the form of mm/dd/yyyy. And to make matters more
complicated the dates aren't shown as the year 1900, they are shown as
the year 2000.

Here is a sample of the code that I think is the culprit

select meaccept

do while .not. meaccept -> (eof())
    if meaccept ->d_accepted >= date() - 30   if I remove calculation
       if meaccept ->his_stk_bo = "y"         I see all of my data.

              statements
       endif
    endif

enddo

Could somebody pleas explain to me why this is not working with year
2000 data.

* Sent from RemarQ http://www.*-*-*.com/ The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!



Tue, 02 Jul 2002 03:00:00 GMT  
 Y2k issue

Quote:

> In one of my applications written in clipper, it selects data >= to the
> current date minus 30 days.  Since the year 2000 has hit the scene, no
> records with the year 2000 are selected and shown on the screen when
> the application is executed.

> So far I have updated the DBU.EXE with set epoch to 1980 and set
> century. Because of this when I execute the DBU utility I see dates in
> the database in the form of mm/dd/yyyy. And to make matters more
> complicated the dates aren't shown as the year 1900, they are shown as
> the year 2000.

> Here is a sample of the code that I think is the culprit

> select meaccept

> do while .not. meaccept -> (eof())
>     if meaccept ->d_accepted >= date() - 30   if I remove calculation
>        if meaccept ->his_stk_bo = "y"         I see all of my data.

>               statements
>        endif
>     endif

> enddo

> Could somebody pleas explain to me why this is not working with year
> 2000 data.

A common scenario is that data meant to have a year of "20xx" that was
entered before the code was fixed for Epoch was quietly interpreted by
Clipper as "19xx", and stored as such. In other words, fixing the code
now won't retroactively fix data that got into the system (incorrectly)
earlier). If the data made it into the .dbf file with the correct
century digits, as you're suggesting, it should be visible. Date
arithmetic involving stored Date-type data isn't affected by Epoch or
Century settings.

Unless perhaps there's a blown index involving a date expression?

Neil
MythoLogics
http://www.mythologics.com



Wed, 03 Jul 2002 03:00:00 GMT  
 Y2k issue

Quote:


> > In one of my applications written in clipper, it selects data >=
> to the
> > current date minus 30 days.  Since the year 2000 has hit the
> scene, no
> > records with the year 2000 are selected and shown on the screen
> when
> > the application is executed.

> > So far I have updated the DBU.EXE with set epoch to 1980 and set
> > century. Because of this when I execute the DBU utility I see
> dates in
> > the database in the form of mm/dd/yyyy. And to make matters more
> > complicated the dates aren't shown as the year 1900, they are
> shown as
> > the year 2000.

> > Here is a sample of the code that I think is the culprit

> > select meaccept

> > do while .not. meaccept -> (eof())
> >     if meaccept ->d_accepted >= date() - 30   if I remove
> calculation
> >        if meaccept ->his_stk_bo = "y"         I see all of my
> data.

> >               statements
> >        endif
> >     endif

> > enddo

> > Could somebody pleas explain to me why this is not working with
> year
> > 2000 data.
> A common scenario is that data meant to have a year of "20xx" that
> was
> entered before the code was fixed for Epoch was quietly
> interpreted by
> Clipper as "19xx", and stored as such. In other words, fixing the
> code
> now won't retroactively fix data that got into the system
> (incorrectly)
> earlier). If the data made it into the .dbf file with the correct
> century digits, as you're suggesting, it should be visible. Date
> arithmetic involving stored Date-type data isn't affected by Epoch
> or
> Century settings.
> Unless perhaps there's a blown index involving a date expression?
> Neil
> MythoLogics
> http://www.mythologics.com

I'm not sure what you mean by a blown index involving a date
expression.  I just started learning the Clipper language.  I didn't
know that expressions had their own indices.  If this is the case is
there a way to rebuild the index.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!



Wed, 03 Jul 2002 03:00:00 GMT  
 Y2k issue

Quote:
> I'm not sure what you mean by a blown index involving a date
> expression.  I just started learning the Clipper language.  I didn't
> know that expressions had their own indices.  If this is the case is
> there a way to rebuild the index.

There is usually an index used with a .dbf file, and that index file
defines the sequence in which the .dbf records are viewed when stepping
through them. If a record is not in the index, your code won't "see" it,
and it won't go through the code loop that you posted. That's why I
suggested that you might have a damaged index.

The index is built by evaluating an expression against the data in each
record and constructing a tree based on that sequencing. Index
expressions can be simple or complex, and can involve multiple fields
and functions to manipulate them. Indexes can be a bit fragile, and a
damaged index is probably the most common cause of "disappearing"
records. Your application probably has a maintenance menu or a
standalone indexing utility program that allows you to rebuild the
indexes.

Neil



Wed, 03 Jul 2002 03:00:00 GMT  
 Y2k issue
onyx

You rebuild the index the same way you created it in the first place (syntax
wiil change slightly with which ever RDD your using).
INDEX ON <SomeField> TO <SomeFile.Ext>
INDEX ON <SomeField> TAG <SomeTagName>TO <SomeFile.Ext>

Expressions don't have indices, indices can be created/re-built using
expressions.
eg
No Expression in Index key
USE FLINTSTONE VIA "DBFCDX" EXCLUSIVE
INDEX ON DATEFIELD1 TAG "FREDSDATE"

Expression/Function used (DTOS()) in Index key
USE FLINTSTONE VIA "DBFCDX" EXCLUSIVE
INDEX ON DTOS( DATEFIELD1 ) TAG "FREDSDATE"
or
INDEX ON DTOS( DATEFIELD1 ) + STR( RECNO(), 8, 0 ) TAG "FREDSDATE"

--
HTH
Steve Quinn
Are part-time band leaders semi-conductors?
Do jellyfish get gas from eating jellybeans?
How do you write zero in Roman numerals?
How many weeks are there in a light year?


Quote:



> > > In one of my applications written in clipper, it selects data >=
> > to the
> > > current date minus 30 days.  Since the year 2000 has hit the
> > scene, no
> > > records with the year 2000 are selected and shown on the screen
> > when
> > > the application is executed.

> > > So far I have updated the DBU.EXE with set epoch to 1980 and set
> > > century. Because of this when I execute the DBU utility I see
> > dates in
> > > the database in the form of mm/dd/yyyy. And to make matters more
> > > complicated the dates aren't shown as the year 1900, they are
> > shown as
> > > the year 2000.

> > > Here is a sample of the code that I think is the culprit

> > > select meaccept

> > > do while .not. meaccept -> (eof())
> > >     if meaccept ->d_accepted >= date() - 30   if I remove
> > calculation
> > >        if meaccept ->his_stk_bo = "y"         I see all of my
> > data.

> > >               statements
> > >        endif
> > >     endif

> > > enddo

> > > Could somebody pleas explain to me why this is not working with
> > year
> > > 2000 data.
> > A common scenario is that data meant to have a year of "20xx" that
> > was
> > entered before the code was fixed for Epoch was quietly
> > interpreted by
> > Clipper as "19xx", and stored as such. In other words, fixing the
> > code
> > now won't retroactively fix data that got into the system
> > (incorrectly)
> > earlier). If the data made it into the .dbf file with the correct
> > century digits, as you're suggesting, it should be visible. Date
> > arithmetic involving stored Date-type data isn't affected by Epoch
> > or
> > Century settings.
> > Unless perhaps there's a blown index involving a date expression?
> > Neil
> > MythoLogics
> > http://www.mythologics.com

> I'm not sure what you mean by a blown index involving a date
> expression.  I just started learning the Clipper language.  I didn't
> know that expressions had their own indices.  If this is the case is
> there a way to rebuild the index.

> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!



Thu, 04 Jul 2002 03:00:00 GMT  
 Y2k issue
My problem has been solved.  My message here today is to first and
foremost thank my Lord and savior Jesus Christ for using you guys to
help me to solve my problem.  You guys were outstanding in helping to
solve this problem.  The problem was solved when I created a new
DBU.EXE and I re-indexed the database, thus creating a uncorrupted
index. Thanks again.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!



Thu, 04 Jul 2002 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Clarion 2.1 Y2K Issue patchy2k.exe no work!!

2. Y2K Issues in CDD for DOS

3. Any Y2K issues for CPD v2.1

4. Need Urgent Help- Y2K issue

5. New Y2k Issue

6. Y2k Issue

7. Y2K Issues

8. OT: OS/390 Y2K issue

9. Only one real Y2K issue left

10. Simple question on the Y2K issue

11. cgi.tcl y2k issue(?)

12. Query -- Y2K issues in "legacy" Tcl/Tk (not in FAQ)

 

 
Powered by phpBB® Forum Software