I would strongly discourage you from putting database I/O and a display
screen in the same procedure -- or even the same module.
One of the basic ideas that's important moving forward is to have each
routine do only one thing (and do it well). Reading a database is
hardly the same thing as displaying data on the screen. What if,
somewhere down the road, you want the same database logic to be used in
a batch program? Or from a web application? or an SQL function, etc?
Keep your display logic separate from your business data. Put the
database access, along with any business rules, in one module. Put the
display logic, along with the handling of function keys loading
subfiles, and other routines related to displays in it's own module.
Here are some articles from System iNetwork that you might find
useful... you'll need a System iNetwork membership to view them. The
first one only requires a free ("Associate") membership. The others
would normally require a ProVIP membership, but right now the whole site
is available to free members... (I'm not sure when they plan to put the
locks back on?)
Jeff Young wrote:
I have a function that will perform DB I/O and possible require a
This function will accept 1 parameter and return 1 parameter. This
function will be called from a number of programs.
Should I - A. Make it a service program B. Make it a bound modue C.
Make it a stand alone program called by others as needed.
This mailing list archive is Copyright 1997-2020 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