Darrell wrote:
In a number of cases, we use different members to hold data that is
pertinent to different ... functions? departments? users?
I appreciate that. I used to argue with a number of former colleagues about
whether to allow multiple member files in new database designs, which they were
adamantly opposed to because their highest priority was cross-platform support,
and multiple member files are a System i centric feature.
Those who favor SQL for database I/O also generally seem to oppose the use
multiple member files which are not very well supported under the ANSI SQL
standard.
The only way I know of supporting multiple members with SQL is to perform
member overrides first, and most SQL developers don't want to be bothered with
that, plus they're more likely to be on the cross-platform bandwagon too.
But if you add some plumbing which allows users to call a program that
automatically performs all overrides for all files within a given application,
regardless of whether the application is using Query, or native record level
access, or STRSQL, or an ODBC interface - it makes multiple member files more
palatable to users.
Nathan M. Andelin
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
midrange.com
