Re: RE: logical view over mult files -- MIDRANGE-L

Ahhhh sorry, that makes more sense. Lets see if I understand.
Fin_Product is File1
Components is File2
Interm_Product is File3
Raw_Materials is File4

At any point in time, data from all 4 files may need to be displayed to 
different users, but the primary file could be ANY one (or more - depending on 
the data needed to be looked at) of these 4 files. For a total of 24 different 
combinations of joins.
Hmmmmmm - interesting project. 
Please let me know if my understanding of your request is correct as the 
project I've just described intrigues me.

>>> "Sam Kanakanui" <skanakanui@triad.rr.com> 12/12 10:54 AM >>>
Thanks, Alan.

That would work for simple reporting.  But what we need is more of a dynamic
function where a user may key a finished product and all it's levels, and
1/2 an hour later, somebody else wants to view that finished product on a
screen by keying in the SKU.

Thanks again,
Sam


-----Original Message-----
From:   owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com] 
On Behalf Of alan shore
Sent:   Tuesday, December 12, 2000 9:24 AM
To:     MIDRANGE-L@midrange.com 
Subject:        Re: logical view over mult files

We have somewhat of a similar problem. I was going to use OPNQRYF or SQL,
but to show the end-user what I was attempting to explain, I wrote something
quick and dirty in QUERY.
Step 1 Create a QUERY joining file 1 to file 2 (Fin_Product to Components)
creating a new file, fileZ (Fin_Product/Components) with the neccessary
fields from both files).
Step 2 Creat a QUERY file Joining fileZ to Interm_Product creating fileY
(with the neccessary fields from both files).
Step 3 Create a QUERY file joing fileY to Components creating fileX (with
the neccessary fields from both files).
Step 4 Create a QUERY file joing fileX to Raw_Materials creating fileV (with
the neccessary fields from both files).

As NONE of these files was that large, or changed that much, my example that
I presented to the User ended up being the final product.
Quick and dirty? yes
Ineffecient? Yes.
Does it give what the user requires? Yes - right now. As these files expand,
or change more often, I may need to revisit this whole episode,.
The moral of this story is just give it a go with whatever you feel
comfortable with. You never know, the quick, dirty, cheapest (probably most
inefficient) method may suffice.


>>> "Sam Kanakanui" <skanakanui@triad.rr.com> 12/12 7:28 AM >>>
Hello,

I am trying to extract data from a BOM system with preferably a single view
of the data.  The data is stored in 4 files. Fin_Product, Interm_Product,
Raw_material, and Components.  The linking is as follows.

The level 1 SKU in Fin_Product links to one record type in the Components to
get the level 2 SKU.
The level 2 SKU must link to Interm_Product.
Then, the level 2 SKU links to a second record type in the Components to get
the level 3 SKU.
The level 3 SKU must link to Raw_Materials.

The end result would be to allow a user to view a SKU in Fin_Product and see
specifications of both level 2 SKU and level 3 SKU from Interm_Product and
Raw_Materials, respectively.  I first thought of somehow joining the files
with DDS or SQL but don't know if this might be too complex for that.  I
know I can write an RPG program to do this with chain to the different
levels. However, there are a number of varying requests, i.e. different
reports and screen inquiries with different parameters, that are needed.  It
would be nice to have a way of getting to the needed data at the DB level.

Does anyone have any suggestions?  Would a canned data mining tool work in
this scenario?  Which one?

TIA,
Sam Kanakanui
Borg Systems, Inc.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com 
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com 
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com 
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---