|
Message text written by INTERNET:MIDRANGE-L@midrange.com >I can do this, just wondering if anyone has any serious reason why you >can't do this? The most serious reasons won't be apparent until they get run over by them. But as already mentioned, any dates that are used for aging purposes, such as accounts receivable/payable, tracking expiration for products, contracts, etc,etc,etc. If they do it (let's say it would work), they'd have to: 1) Identify those fields in files where dates would have to be adjusted for aging. The same software packages that age data forward for Y2K testing could probably do this. (Have fun finding all those dates you want to muck with ahead of time.) 2) Identify those fields for reports going outside the company where dates being printed would have to be adjusted back to reality for cosmetic purposes. Those pgms still have to be adjusted, and remember that at some point those changes will probably get undone, so they better be well documented. 3) How are they going to handle leap year processing? They would have to set the date back by a number of years divisible by 4. Depending on their data requirements they *might* get away with this-if for example, the data cycle is short (ie, if they don't really do processing with data more than one year old) they might be able to do this for one year, then force all the date data forward where it should be, and undo any Y2k specific programming changes originally put in to adjust the backdated data. I don't like it as a solution, but if carefully done, for *some* companies, it may be a cost effective 'workaround'. Alternatively, it may be used internally as a workaround for subsets of in house data (aging the data backwards only in some files, but not setting the system date back)-which presents a whole other set of issues... :-p -Ilena Ayala +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.