On Apr 8, 12:52*am, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Hi
I have done this on several occasions thanks to the intrusion of SAP
into the oil industry.
Because I use a global schema for my application it is quite
straightforward. In fact I was able to incorporate the SAP junk into
a larger scheme that allowed the customers to continue using the
appropriate non SAP items as well.
In the case of the oil industry a distributor will have a significant
amount of stock from places other than the SAP enforced codes from the
major oil company. In fact we used the new requirement to even
greater benefit by putting in a xref that allowed the user to enter 1
for diesel, 2 for Unleaded etc and I looked after the SAP for the
major items.
Every application has its own issues of course. I am horrified that
anyone would allow a file to get to 10Gb as I use archives but I
assume that there is a good reason. I disagree on principle that one
would go and change the earlier items and would use xref with
expiration flags if possible. However every application has its
quirks and I assume there is a reason.
It is certainly a strong point for establishing programming standards
and enforcing them, which we have always done.
Peter McMurray

On 2011-04-07 17:32:16 -0400, Excalibur21 <pgmcmurray (AT) gmail (DOT) com> said:
Yes, it's nice if you're there from the beginning, but some of the
systems I care for now had close to 20 yrs of "interesting" practices
from multiple "programmers" before I got to them. In some cases, you
just have to live with what's there because nobody wants to pay for an
under-the-hood rewrite that appears to give them no new functionality.

--
Kevin Powick

I'm not advocating, just commenting.

Even with yiour sequential ID's you can still come unstuck if you
wanted to "merge" multiple products, so special logic is likely to be
required ..... and if people had hard coded logic based on a
particular product code, well, I hadn't considered stuff like that
'cause it isn't the way I'd do things.

I doubt that different logic would be required for different
files .... I hadn't considered this as being significant, and
certainly no more so that the use of "meaningless ID's" (which in turn
would sugffer from that "hard coded logic issue" .... I won't even
touch HOW you would hard code for a random number :-)

A "well maintained" central repository would ensure that you knew
every file & dictionary item that would be impacted, so there should
be no risk of missing files or fields --> the investment of getting
this repositiory right is that the work only needs to be done ONCE
(assuming ongoing maintenance for new files/fields) ... and yeah, I
know that most people don't have such a thing, and that this is a non-
trivial task (we have around 17,000 discrete dictionary definitions
for our R5 application), but the results can then also be used to
better project your data out into other products/tools/"things"

Anyway, a long way from casing unless we digress further into
DictionaryNamingConventions, so I'll leave off :-)

On Apr 8, 2:24*am, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
Agreed --> and didn't want to do a point by point dissection, and as
you said, some of the points are valid, especially relating to history
and the fact that whilst changes were taking place, system for
affected items would be in a state of flux until complete, but this
may be able to be scheduled for "out of hours" if there is such a
thing these days!!!)