🚀 go-pugleaf

Keith G. Chuvala (TeamB) wrote:
> 
> > > Multi-member tables were another story, but they're problematic for
> > > ODBC anyway, so I already had logical files (akin to SQL views) set up on the
> > > AS/400 for those situations.
> > >
> > --------------------------
> > Could you comment a bit more on this 'problem'?
> 
> Under the native AS/400 database, each database file can contain multiple sets
> of records, each uniquely addressable and called a "member" of the file.  For
> example, we track customer data for two distinct product lines, motorcycles
> and automobiles.  So each of the tables in our buyer database cintains two
> members, one called "AUTO" and the other called "MC".  Some of our tables have
> 10 or even more members depending on the need.
> 
> You can create logical views of these tables that exspose only a specific
> member, all members, or what have you.  So while the physical file BYR01PF,
> for example, has both AUTO and MC members, we create a corresponding logical
> file called BYR01MC which is built to access the MC member only.
> 
> The problem with the various AS/400 ODBC drivers I've used is that they only
> "see" the first or default member of a given table (in our case, AUTO, since
> they're exposed alphabetically).  So if I want to get to the MC member data of
> a given from a dBASE app, I have to have previously created a logical view as
> described above for that file.
> 
> It's a pain, but not terribly hard to work around.  The Delphi/400 and C++
> Builder/400 products incorporate native AS/400 support that allows you to
> address member issues directly from your client-side application, but then of
> course we'd have to write everything in Delphi or C++B, which I'm reticent to
> do. :)
> 
-----------------------
Thanks for the insight, Keith.

-- 
Regards, Cecil.

[email suffix:  bc dot sympatico dot ca]