|
There is an interface or server program that helps convert. Just found that and Carl also mentioned it. Possibly the Julian logic is better it's just that it is so foriegn in some cases. We have always used Gregorian as a storage approach......now this. JDE does support multiple OS's (Unix, NT, and OS/400) and RDBMS's (Oracle, SQL Server, and DB2/400) so there may be a factor in that. Version 7.3 is an AS/400 only release but the current version 8 is supported on these other platforms. And JDE also has some of their own report tools............fortunately we are moving towards Showcase Strategy that seems to have some fair amount of integration with JDE. Of course, there is all the legacy stuff that we have to change...... They could have made this a lot easier IMO. One general observation, JDE does it's best to force you to use all of their stuff and all of their 'annointed' third party add-on's. Call it what you will I don't think they integrate well. I have a love/hate relationship with them. The software we use works pretty well and most of our users are happy. But they are a pain in the posterior to integrate and support in our environment. Plus I think they tend to market the software beyond it's capability - I think they have learned something from MS. Oops, sorry. I should have notified you about the soapbox/rant mode.......it's off now. Anyway those opinions mine and not those of my employer..... One question though. Am I being picky and thinking it's stupid to use a century bit? Why not true Julian? This makes no sense to me either. Couldn't they call a standard routine which does all of their date processing? If so they could have kept that other date format. While I wouldn't have done it that way, it was effective. Does JD Edwards support multiple platforms? If so, maybe the reason that they chose the new date versus the new date field formats is because some database systems either are buggy or do not support date fields. If that was the case perhaps they should have adopted CCYYMMDD. Let's figure. CCYYMMDD packed takes 5 bytes. XYYJLN packed takes 4 bytes. A one million record file with three date fields would then take an additional (1byte difference/field) * (3 fields/record) * 1,000,000 records/file) = 3MB. 3MB * ($0.60/MB, cost of AS/400 disk space) = $1.80. Gee you think they'll spend more then that trying to process this strange date? Or, (conspiracy theory time), does JD Edwards market a report writer? With Query being so friendly they probably had to come up with a way to make you jump through more hoops to use dates and attempt to beat you into submission into purchasing their report writer. mcrump@ballfoster.com on 10/15/98 11:42:49 AM Please respond to MIDRANGE-L@midrange.com@Internet To: midrange-l@midrange.com@Internet cc: Subject: JD Edwards Dates Somewhere along the line I must not be living right because I seem to be paying for it now... We are in the process of upgrading from JDE A6.2 to A7.3. We just came across the documentation for date storage. Historically, JDE has stored stuff in Gregorian format in four seperate fields DD, MM, CC, and YY. Now in 7.3 all dates are being changed to 'Julian'. The format is XYYJLN where X is a centery flag(0 = 19, 1 = 20), YY is year, and JLN is the Julian day within a year. According to their documentation, and I quote, 'Julian date processing allows for the use of a single field, eases manipulation, sorting, and calculation of dates'. I'm real frustrated because we have to change a lot of access points. Multiple systems, DDM files, modifications, and query tools. Am I missing the boat or does this change make sense.......besides benefiting JDE? Respectfully but pretty ______ off, Mike +--- | 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.