Re: JD Edwards Dates

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
+---