|
I think we all were taught a similar rule and would have to agree that it makes perfect sense. Unfortunately, as a programmer, I am at the mercy of the ERP package selected by the business users. If the ERP has customer NUMBERS and document NUMBERS, I am stuck with them. Any new development that I do that interacts with the ERP files/servers/etc. gets to perpetuate the problem. My last shop, at one point, has two different packages, one for order entry and one for manufacturing. We had interface programs coming out of our ears to get these two packages to try to work together because one package used the 'numeric rule' and the other did not. The OE software on AS400 number 1 kept a customer id in a 7 alphanum field. The MFG software installed on AS400 number 2, had a customer number defined as 8 numeric. Eventually, we exceeded the available numbers on the OE side. So, of course, we implemented a character conversion for rollover. The interface responsible for transmitting the orders from OE to MFG had to convert, for example, customer id A123456 to 10123456 before sending it to the MFG box. So, do I agree with the rule? Heck yeah. I follow it whenever possible on new development that can act independent of the existing ERP. What are my chances of convincing the business to scrap a multi-million dollar package installation because of its poor design? Pretty slim - on a good day. I've got a better shot at winning the lottery - twice in the same month. jw ______________________________ Reply Separator _________________________________ Subject: RE: just curious - Number of Parms(numeric zip codes and oth Author: Joel Fritz <JFritz@sharperimage.com> at Internet Date: 07/28/2000 8:57 AM I was taught a very simple rule on when to use a numeric--"Will it be used in computations; does it represent a quantity; or does it show order? If yes to any of the above, use a number, otherwise use a character variable." I think we could debate the order criterion at length, although numbers are pretty darned easy to increment. I've seen ZIP codes stored as numeric because "It takes up less space," or "It's easier to format ZIP +4 with edit words." Same thing with phone numbers. The real fun is using Query or RPG to join files by ZIP code when you have character in one and numeric in the other. > -----Original Message----- > From: Gary Guthrie [mailto:GaryGuthrie@home.com] > Sent: Thursday, July 27, 2000 9:48 PM > To: RPG400-L@midrange.com > Subject: Re: just curious - Number of Parms > > >> > Limiting the conversation momentarily to the USA, Zip Codes often are > defined as numeric. In fact, in the not so distant past, they were > defined as 5 digits in length. Of course, 9 is a more > appropriate length > now. But, all of a sudden your company decides to do business > outside of > the USA -- hmm, now we need alpha characters, too! And, > there's nothing > that prevents USA standards to change to allow alpha characters. > > This having been said, I submit that it's best to leave numeric > definitions to those entities that indicate quantitative data > and avoid > the type of problems mentioned. > > Thoughts? > > Gary Guthrie > REAL Solutions Technical Support > NEWS/400 Technical Editor +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-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.