From: Chris Ringer To: All
Does anyone out there know how to make sure the user enters a value in a field that falls within a certain range? For example, if a part price (all part prices) should be in the range $25 to $500, do you just trust that the operator will enter a value that falls within that range, or do you somehow edit for this? And, if you edit for this, do you hardcode the range in your program, or do you setup the range in a database?
From: Ernie Malaga To: Chris Ringer
DDS has the RANGE keyword to do precisely what you want. You can code this in your database file or in the display file used to input data. Since the price values can change frequently, I recommend against coding it in the physical file; you'd have to recompile the physical file when you wanted to change the range of prices--and this means a lot of work, especially if you have logicals built over it.
For all intents and purposes, it's best to do it in the display file only, as shown in 5 (page 66).
For all intents and purposes, it's best to do it in the display file only, as shown in Figure 5 (page 66).
Coded like this, the value entered for PRICE must be between $20 and $150. Any other value would cause a workstation error; the user would have to press Error Reset and type another value.
From: Carter Combs To: Ernie Malaga
I have to respectfully disagree with you on this one. Going back to the database axiom "Define it once", your method is a step backwards. What if you have several screens where the field can be changed? For example: POSTING_PERIOD is defined with range (1-12), and dozens of screens ask for this field, then you change to 13-period accounting. Would you rather change it once in your field reference file, or hope you find all occurrences? In my opinion, any time you change a field attribute, whether range or length or whatever, you should recompile and copy the affected files.
From: Ernie Malaga To: Carter Combs
You're correct. What I was saying is that it's a pain having to recompile the physical file, especially if you've built logicals on top of it. Chris Ringer's question was if there was a way to limit a price field to a certain range of values. Well, considering that prices change so much, it made more sense to change the display file's RANGE keyword rather than the physical file's. Prices are as fickle as the person who controls them. All it takes is a marketing change-of-mind and off they go. I couldn't imagine myself recompiling the physical file each time (doing whatever was necessary not to lose the data), so I suggested to recompile the display file only. But I agree that your suggestion makes more sense for the less variable data.
TechTalk: Field Ranges
Figure 5 Using the RANGE keyword
Figure 5: Using RANGE Keyword A R RECORD A PRICE 7P 2 EDTCDE(4) A RANGE(20.00 150.00)
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online