Hi Birgitta

We use data areas a lot in our products. They are used for next number, as Jeff mentioned. They also hold various settings, so that customers can change the behavior of our product. For example, we have a setting for whether any user has access to all document types, or if that access is controlled by user. Those kinds of things are not easy to change if they are in global variables in a service program.

We don't use tables - I think that tables are a big hammer for a simple, small nail. Retrieving values from data areas has to much lighter in processing than opening and reading tables.

Also, if we change some behavior, we often add a data area with a setting that defaults to the old behavior. Again, this makes things easy for customers.

We have some commands to make it easier to manage these values. I do think we should maybe put up a properties panel, which would make maintenance even simpler.

And it was fantastic to see you at COMMON. You were a big hit with all those SQL sessions!

HTH
Vern

On 5/13/2011 10:17 AM, Birgitta Hauser wrote:
Hi guys,



we just had a discussion about using data areas.

In my opinion they are not heavily used or needed.

I either create a table/physical file or store the information in global
variables in a specific service program. The data within these global
variables is set and retrieved by calling procedures.



I’m just curious, are you using data areas (heavily) or not?



Mit freundlichen Grüßen / Best regards



Birgitta Hauser



"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)

"If you think education is expensive, try ignorance." (Derek Bok)

"What is worse than training your staff and losing them? Not training them
and keeping them!"




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].