× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.