Jeff,

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?)

http://systeminetwork.com/node/60047
http://systeminetwork.com/article/pattern-recognition-ease-modern-rpg-programming
http://systeminetwork.com/article/pattern-recognition-adopting-pattern
http://systeminetwork.com/article/how-write-service-programs
http://systeminetwork.com/article/considerations-successful-ile-implementation


Jeff Young wrote:
All -
I have a function that will perform DB I/O and possible require a
display window.
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 thread ...

Replies:

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

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 [javascript protected email address].