Oracle 8i SQL - Dealing with no records matching a value

Question

Warning: before you read this, please understand I'm no expert on SQL, so it's quite likely I screwed something obvious up...
I'm trying to do a query kind of like the following:
SELECT
BOM.COMPONENT, BOM.QTY_PER, BOM.PARENT, BOM2.PARENT_QTY_PER
FROM
BOM BOM, BOM BOM2
WHERE
BOM2.COMPONENT=BOM.PARENT AND
BOM.TOP_ASSY='ABC-123'
(Don't worry about my punctuation, my company only allows me to do [read-only] queries through Excel, so I don't need the semi-colons)
What I'm doing is pulling information from the bill of materials (BOM) for a particular assembly (BOM.TOP_ASSY). Each assembly has components (BOM.COMPONENT), and each component has a parent part (BOM.PARENT), which it goes into. Each parent part will also have its own parent part, unless the parent part is the assembly for which I'm querying (BOM.TOP_ASSY) - in the example above, the assembly I'm looking for is 'ABC-123'.
This leads me to my problem. Since I'm looking for the QTY_PER for both the component and the parent, I have to refer to two separate copies of the BOM table. And, since BOM.PARENT could equal BOM.TOP_ASSY, and BOM.TOP_ASSY has no parent, so it can't be a component, so it would never be in the column BOM.COMPONENT. Thus, when I run this query, all components that go directly into the top assembly ('ABC-123') are left off the query.
Is there any way to retrieve the records for the components that go directly into the top assembly, and just make BOM2.PARENT_QTY_PER equal to 0? Basically, I only want BOM2.PARENT_QTY_PER to equal something if the parent is also a component, but 0 if it's the top assembly.
Using NVL doesn't help, and since I'm stuck with an Oracle 8i database to query, I can't use CASE...WHEN either (though, I don't even know if this is possible with a case statement or not)...
I don't even know if this is possible, but could someone let me know one way or the other?
Thanks so much!

Answer 1

Hi,
user11033437 wrote:
The whole example with the BOM and BOM2 tables were just an example of what I'm actually doing. What I'm actually doing is much more complex, and since it's all in VBA code, it was much easier for me to make up a simple example then to actually get my SQL out of VBA That's an excellent approach! I suggest you continue with it. Make sure the tiny test situation works as posted, and then, when it does work perfectly, make it a little more like your real case (say, add just one more condition in the WHERE clause), and test again.
(which looks like this:
strSQL = "SELECT "
strSQL = strSQL & "C_BOM.BILL_LEVEL, "
strSQL = strSQL & "C_BOM.COMP_PART_NBR, "
strSQL = strSQL & "C_PART.PART_DESC, " )
But, in the interest of getting my query to work, and hopefully learning a few things in the process, I've extracted my actual SQL, and pasted it below:
SELECT
     C_BOM.BILL_LEVEL,
     C_BOM.COMP_PART_NBR,
     C_PART.PART_DESC,
     C_PART.PART_TYPE,
     C_BOM.QTY_PER,
     C_BOM.BOM_UM,
     C_BOM.BOM_DOC_NBR,
     C_BOM.OPER_NBR,
     C_BILL.COMP_OFF_ADJ,
     C_PART.QTY_ON_HAND,
     P_PART.QTY_ON_HAND,
     NVL(P_BOM.QTY_PER,0)
FROM
     PART C_PART,
     PART P_PART,
     BILL C_BILL,
     V087_BOM C_BOM,
     V087_BOM P_BOM
WHERE
     C_PART.PART_NBR=C_BOM.COMP_PART_NBR AND
     P_PART.PART_NBR=C_BOM.BOM_DOC_NBR AND  --fixed a typo here from extracting from vba
     P_BOM.COMP_PART_NBR (+) = C_BOM.BOM_DOC_NBR AND
     C_BILL.COMP_PART_NBR=C_BOM.COMP_PART_NBR AND 
     C_BILL.BOM_DOC_NBR = C_BOM.BOM_DOC_NBR AND
     ((C_BOM.STATUS = 'RL') AND
     (C_BOM.PART_NBR= 'ABC-123') AND
     (C_BOM.END_EFF_DT>sysdate) AND
     (C_BOM.BEGN_EFF_DT<=sysdate) AND
     (C_BOM.VIEW_CODE<>'E') AND
     (P_BOM.STATUS = 'RL') AND
     (P_BOM.PART_NBR= 'ABC-123') AND
     (P_BOM.END_EFF_DT>sysdate) AND
     (P_BOM.BEGN_EFF_DT<=sysdate) AND
     (P_BOM.VIEW_CODE <> 'E') AND
     (C_BILL.VIEW_CODE <> 'E') AND     <--for some reason my <> is being parsed out here
     (C_BILL.QTY_PER_TYPE <> 0) AND  <--for some reason my <> is being parsed out here
     (C_BILL.END_EFF_DT>sysdate) AND
     (C_BILL.BEGN_EFF_DT<=sysdate))
ORDER BY
     C_BOM.BILL_LEVEL, C_BOM.BOM_DOC_NBRPART is the table with the information associated with each part in the system
BILL is the table with the bill of materials for each assembly in the system
V087_BOM is a view that I didn't create, but seems to compile the full bill of materials (from the BILL table) for a top-level assembly (so, the BOM for that part, and for all of it's sub-assemblies, and all of their sub-assemblies, etc.)
Does that give a clearer picture of what I'm trying to accomplish?
Edited by: user11033437 on Apr 15, 2009 10:07 AM
Fixed a typo where indicated (P_PART_NBR changed to P_PART.PART_NBR)I see where you made the join condition between p_bom and c_bom an outer join:
P_BOM.COMP_PART_NBR (+) = C_BOM.BOM_DOC_NBRThat says: "join the tables like this if possible, but if there's no match, then pretend there was a match in the table marked with the + sign". The resuolting joined row will have bom_doc_nbr (and all the other columns from c_bom), but comp_part_nbr (and all the other columns from p_bom) will be NULL.
One of those columns is status. Your WHERE clause includes the condition:
(P_BOM.STATUS = 'RL')Since all columns from p_bom are NULL in this case, the condition above will fail, even though the first condition succeeded.
You have to add a + to all the conditions in this query that refer to p_bom, including
...     (P_BOM.STATUS (+)      = 'RL')      AND
     (P_BOM.PART_NBR (+)    = 'ABC-123') AND
     (P_BOM.END_EFF_DT (+)  > sysdate)   AND If you want to include rows that have no match in the p_part table, you'll have to make all of its conditions outer-joins, too:
     P_PART.PART_NBR (+) = C_BOM.BOM_DOC_NBRIsn't that annoying about the &lt;&gt; operator? This site treats it as some kind of markup, even inside &#123;code&#125; tags. I'm surprised any of them showed up. Thanks for flagging them with comments.
There's no problem with the other inequality operator, !=. You can use that when you post to this site.