SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : 2000 Date-Change Problem: Scam, Hype, Hoax, Fraud

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: David Eddy who wrote (279)10/8/1997 11:18:00 AM
From: Jeffrey S. Mitchell   of 1361
 
And at the very bottom are folks who had their precocious neighbor write their inventory control system in dBase... now you're in real trouble.

Hey, I represent that remark!

FYI, dBase, from day one, always had a "date" data type that stored dates as characters with 4 digit years. If you add "Set Century On" to your code you are instantly Y2K data entry/displaycompliant.

The problem arises in how programmers (like me) used to handle default dates for reports and write our own date functions. For example, I would always say "leave date range blank to include all records"-- and then default the date from "01/01/01" to "12/31/99". I could go on and on, but suffice to say there are countless "textbook" examples of how to write date functions based on a user entering an 8 character date.

So, yes, old dBase code most likely has countless places where program logic must be changed, and, yes, there's tons of it out there. And yes, the source code is usually not with the customer! Sounds like people like me that wrote that stuff could make a killing fixing old dBase code. Well, sorry, not interested! I think I speak for many when I say I'd sooner pull out dandelions in my yard than remediate old dBase code. (gg)

- Jeff
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext