![]() |
![]() |
|
![]() |
Subject: FAQ:PdoxWin:Y2K Advice:1999.09.21 Version 1.0 (1999.09.20) edited by Paradox FAQ Team Reposted 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 mentioned in the "FAQ: FAQ FAQ" document. Please preface the subject of your post with the string "PDXWIN FAQ" to alert Team members to the function of the message. Please specify the FAQ name and section number the comment applies to, if any. ==================== 1. General Y2K information ==================== What is Y2K problem anyway, 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, Windows 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 this in NO WAY means 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 Windows Y2K information ==================== The official Borland/Inprise Y2K position on Paradox older than version 7 (32-bit version) is "will not test, assumed NON-compliant". That includes PDOXWIN1, 4.5, 5, and 7 (16-bit version). Paradox 8 and Paradox 9 are rated as "fully Y2K compliant" by Corel. See http://venus.corel.com/y2k/ for details. Paradox 7 is rated "Compliant with issues". See http://www.borland.com/about/y2000/paradox.html The problem with Paradox is two-fold. Paradox is dependent on the BDE, or Borland Database Engine. The BDE must be compliant or Paradox will not be. For BDE Y2K status, see http://www.borland.com/about/y2000/bde.html In short, BDE 5.01 and later are fully Y2K compliant. These versions of BDE are for 32-bit platform only. -------------------- 3.1 So what do I do about my PDOXWIN apps? -------------------- If you are still on WIN3X, upgrade to WIN9X ASAP. Then get the latest 32-bit version of Paradox. The programs and such should run AS IS with no modifications except you will have to recompile and redeliever all the objects. Then upgrade to latest version of BDE available, and that should take care of the developement side. If you're on WIN9X already, upgrade to latest version of Paradox and BDE should solve your Y2K problems except for the issues noted, if any. Remember though, you still need to check hardware, operating system, and code for their Y2K status. ==================== 4. Some non-Y2K code to watch for ==================== One of the most frequent non-complaint 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 ObjectPAL example var dt date q query endvar dt=date("1/1/1999") q=QUERY MYTABLE | MYDATE | | CHECK ~dt | endQuery q.executeqbe() The problem here is the ~dt in the query. This tells Paradox to turn the variable dt into a string, then evaluate the query. Do you know what your default date format is? That's what Paradox uses when converting the date into a string. If it's 4-digit year, you are lucky. But why be lucky? Make absolutely sure instead. var dt date stdt string q query endvar dt=date("1/1/1999") stdt=format("D8",dt);which would make it '1/1/1999' anyway q=QUERY MYTABLE | MYDATE | | CHECK ~stdt | endQuery q.executeqbe() 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 an invoice number or other unique key generator that's based on a date or a year. As such a number SHOULD always be increasing, you would assume it 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... This may not cause your code to fail, but your users may well get rather confused ! So watch for functions that calls for date(), datetime(), or today() functions. 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. ![]() |
![]() |
|