Paradox Community
Search:

 Welcome |  What is Paradox |  Paradox Folk |  Paradox Solutions |
 Interactive Paradox |  Paradox Programming |  Internet/Intranet Development |
 Support Options |  Classified Ads |  Wish List |  Submissions 


Paradox Newsgroups  |  Paradox Web Sites  |  Paradox Book List  |  FAQs From The Corel FAQ Newsgroup  



Paradox / DOS Y2K FAQ

Version 1.0 (1999.09.20)
edited by Paradox FAQ Team
Repost by Mike Irwin: 2001.02.05

====================
0. Introduction
====================

Welcome to the Paradox Y2K FAQ. This FAQ addresses the most
frequent Paradox-related Y2K questions asked by new members
of Paradox Newsgroups

and USENET fora.

-------------------------------
 0.1 Legal Info and Disclaimers
-------------------------------

Paradox is a trademark of Corel.
Borland Database Engine (BDE) is a trademark of Inprise.

The information provided in this FAQ is provided "as is" and
is not warranted in any way. The information provided in this
FAQ is not endorsed or authorized by Corel or Inprise in any
shape, form, or manner. The editors claim NO responsibility
for ANY illegal activity regarding this file, or as a result
of someone reading this file.

You may distribute this file, as long as the copies are
complete, unaltered, and are in electronic form only.

-------------
 0.2 Feedback
-------------

Please send feedback in a Corel Paradox newsgroup or the
news:comp.databases.Paradox newsgroup to any of the FAQ
Team (see the FAQ about the FAQ Team). Please preface
the subject of your post with the string "PDXDOS FAQ" to
alert Team members to the function of the message.

Please specify the section number the comment applies to,
if any.

====================
1. General Y2K information
====================

What is Y2K problem any way? You wonder. Here's a quick
answer:

The transition to the year 2000 could potentially affect any
computer system or software application that uses date data.
The "year 2000 issue" (sometimes called the "year 2000 bug"
or "millennium bug") refers to the fact that some computer
systems store the year portion of dates in two-digit form
-identifying 1997 as "97," for example. It was common
practice years ago for programmers to use this approach
because it conserved costly memory space.

The two-digit system works fine until a change in the century
or millennium (a year ending in "00" such as the year 2000)
occurs. Then, computers or other electronic devices programmed
or designed in this way could misinterpret the digits "00" to
mean the year is 1900 rather than 2000. Some also might not
recognize year 2000 as a leap year (the turn of the century is
a leap year just once every four centuries), and so may not be
able to transition properly from February 28 to February 29 to
March 1, 2000. Such devices could fail to function properly
(or at  all) after December 31, 1999 or even sooner, if they
reference dates beyond the year 2000 but were not designed to
do so.

(excerpt from http://www.intel.com/support/year2000/hsba1.htm)

Will it affect you? To be fully Y2K compliant, your hardware,
operating system, developement system, AND CODE must all be
Y2K compliant.

We'll discuss some General Y2K info in Section 2, DOS info in
Section 3, some non-Y2K coding to watch for in Section 4, and
some links to get more info on Y2K in Section 5 to make sure
your hardware and O/S are compliant.

====================
2. General Paradox Y2K information
====================

All versions of Paradox stores dates in Y2K-compliant format,
in that the expression

  date('1/1/2000')>date('1/1/1999')

is true in all versions, Windows or DOS.

However, specific versions may have input-related issues that
may affect its usage after Y2K. The issues are different
depending on the specific versions. That will be explained on
Sections 3 and 4.

Keep in mind that in NO WAY does this mean that your
application is Y2K compliant. To be fully Y2K compliant, your
hardware, operating system, developement system, AND CODE must
all be Y2K compliant. There is no way Paradox can detect and
correct non-Y2K-ready code for you. That is up to you.

====================
3. Paradox for DOS Y2K information
====================

The official Borland/Inprise Y2K position on Paradox older
than version 7 is "will not test, assumed NON-compliant".
That, of course, includes all DOS versions.

See this URL for details --
http://www.borland.com/about/y2000/paradox.html

However, as explained before, Paradox will do the DATE MATH
correctly, even DOS versions.

--------------------
3.1 So what do I do about my PDOXDOS apps?
--------------------

You will have to test it. There's no other way to know, and
if you have suspicions or problems, we may know of a
workaround here. Let us know. There is NO PATCH to make
PDOXDOS Y2K-compliant, since technically, DOS is not Y2K
compliant.

--------------------
3.2 Input Problems, PDOXDOS Y2K
--------------------

Problem  : All 2-digit year input is assumed to be 19XX.

Solution : You can workaround the problem by doing Y2K
           checking yourself. Check the current system date,
           and prefix the year with 19 or 20 as appropriate


--------------------
3.3 Display Problems, PDOXDOS Y2K
--------------------

Problem  : System defaults to 2-digit year output

Solution : Code specific date formats whenever you use a date

====================
4. Some non-Y2K code to watch for
====================

One of the most frequent non-compliant code would be
converting a date into a string without ascertaining what
format the date is in. This kind of error can be REALLY hard
to find if the conversion is implicit rather than explicit.
Here's one example:

dt=dateval("1/1/1999")

QUERY

MYTABLE | MYDATE         |
        | CHECK ~dt      |

endQuery
do_it!

The problem here is the ~dt in the query. This tells Paradox
to turn the variable dt into a string, then evaluate the
query. However, the default date format is... D1, or mm/dd/yy.

Instead, do this...

dt=dateval("1/1/1999")
stdt=format("D8",dt)  ;D8 is mm/dd/yyyy
QUERY

MYTABLE | MYDATE         |
                   | CHECK ~stdt    |

endQuery
do_it!

In general, it's simply a BAD IDEA to store any type of date
as a string. You could store a date as A8, but it would not
be Y2K compliant (MM/DD/YY). Why do it at all? You could
expand it to A10 (MM/DD/YYYY), but it's not comparable
directly (it's NOT in ASCII order unless you change it to
YYYY/MM/DD), and it causes lot of other problems. Just use
the date field!

Another thing to watch for is invoice number or other unique
key generator that's based on a date or a year. As such number
SHOULD always be increasing, you would assume in the rest of
your code to be this way. Then when Y2K comes by, and all of a
sudden your "latest" invoice is way at the beginning of the
table and nowhere to be found...

Make sure you're not using any implicit date to string
conversions. If you must, do the formatting EXPLICITLY to
make sure you're using 4-digit years and such.

====================
5. Some non-Paradox Y2K resources...
====================

ZDY2K: ZDnet's Y2K resource center
http://www.zdy2k.com

Microsoft's Y2K resource center
http://www.microsoft.com/y2k/


Paradox Community Newsgroups


 Feedback |  Paradox Day |  Who Uses Paradox |  I Use Paradox |  Downloads 


 The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation.
 Paradox is a registered trademark of Corel Corporation.


 Modified: 15 May 2003
 Terms of Use / Legal Disclaimer


 Copyright © 2001- 2003 Paradox Community. All rights reserved. 
 Company and product names are trademarks or registered trademarks of their respective companies. 
 Authors hold the copyrights to their own works. Please contact the author of any article for details.