Need assistance with query

Question

Sorry, I'm having a brain freeze on this.
Oracle 10.2.0.4
Sample data:
SQL> conn scott/tiger
Connected.
SQL> drop table employees;
Table dropped.
SQL> create table employees (
  2    ssn varchar2(9),
  3    svc_cde varchar2(3));
Table created.
SQL> --
SQL> drop table accounts;
Table dropped.
SQL> create table accounts (
  2    ssn varchar2(9),
  3    empname varchar2(9),
  4    accountno varchar2(5));
Table created.
SQL> -- insert 3 emp recs for a current employee
SQL> insert into employees values ('123450001','123');
1 row created.
SQL> insert into employees values ('123450001','234');
1 row created.
SQL> insert into employees values ('123450001','999');
1 row created.
SQL> --
SQL> -- insert 2 emp recs for a past employee
SQL> insert into employees values ('123450002','345');
1 row created.
SQL> insert into employees values ('123450002','456');
1 row created.
SQL> --
SQL> -- insert 1 account rec for each employee
SQL> insert into accounts values ('12345001','fred','98765');
1 row created.
SQL> insert into accounts values ('12345002','joe','87654');
1 row created.
SQL> --
SQL> /*
SQL> select * from employees;
SQL> select * from accounts;
SQL> select distinct ssn
SQL> from employees
SQL> where svc_cde <> '999'
SQL> ;
SQL> */
SQL> select  a.empname,
  2          a.ssn,
  3          a.accountno
  4  from accounts a,
  5       employees p
  6  where a.ssn = p.ssn
  7    and a.ssn not in (select distinct ssn
  8                      from employees
  9                      where svc_cde = '999')
10  ;
no rows selected
SQL>What I need is a list of all rows from ACCOUNTS for which the ssn does not have a row with svc_cde = '999', and avoiding the cartesian join stemming from the fact that a given SSN may have multiple employee records with svc_cde <> '999'. So from the above, I need the query to return one row for Joe, ssn='12345002'

Answer 1

Hi,
EdStevens wrote:
Frank -
It seems I mis-spoke. We do have people in the acct table that do not appear in the employee table, and they should NOT appear in the final result. I put together a test for that condition with the code you provided and in my test it worked correctly, but against live data I am again picking up current employees - as identified by have an employee rec with a svc_cde of '999999999'.
Here is my complete test script (raw script this time!)Yes, that's much better.
set echo on feedback on verify on trimsp on tab off
conn scott/tigerI suggest you don't use the Oracle-supplied schemas, like scott, for your own objects. It can cause problems when migrating to a new database. Create a test schema just for jobs like this. (This has nothing to do with your present problem, of course.)
drop table employees; ...
-- insert 3 emp recs for a current  employee
insert into employees values ('123450001','123456789');
insert into employees values ('123450001','234567890');
insert into employees values ('123450001','999999999');
-- insert 2 emp recs for a past employee
insert into employees values ('123450002','345678901');
insert into employees values ('123450002','456789012');
-- insert 1 account rec for current employee
insert into cardacct values ('123450001','current','98765');
-- insert 1 account rec for former employee
insert into cardacct values ('123450002','former','87654');
-- insert 1 account rec for non employee
insert into cardacct values ('123450003','nonemp','76543');The comments are very helpful. It's good to have concise terms like "current" and "former", and I'm not sure I would have understood them without these comments.
... Exactly what I need. But somehow if I run this against live data I also get a hit on the 'current' employee, while the 'non-employees' are correctly filtered out. Can you think of a condition that could throw this, that I simply haven't accounted for in my test setup?Post some sample data that shows the error. I know this may be hard to do, but, unfortunately, if I can't re-create the problem, there's not much I can do to solve it. This is sort of like the rattle in yur car that never occurs when you take it to the mechanic.
Are you saying that there are some current employees (similar to '123450001', who have at least one svc_cde='999999999') who are appearing in the result set? Post an example. Does that employee have so many rows in employees that it's hard to post the sample data? Find out exactly which rows are causing the problem, and post only those rows. That is, say there are 20 rows in employees for that person. Find one of the rows with svc_cde='999999999', and make sure it is always in the sample data. (That row alone should be sufficient to keep the person out of the result set.) Now comment out half of the remaining rows, say 9 rows. Does the problem still exist with the remaining 11 rows (the 10 you didn't comment out, plus the 1 with '999999999' that you'll never comment out)? If so, comment out half of the reamining rows. Does the problem still exist with the remaining 6 rows? If not, add back half of the rows you commented out in the last step. Eventually you should be able to find one row that is causing the problem. Chances are, the cause of the problem, and maybe the solution, will be obvious at that point, but if not, post it here, and say exactly which row you found to cause the problem.
Does the prolem occur with all current employees, or just certain ones? If it's only certain ones, can you see any pattern in which employees have the problem, and which ones don't?
Are you sure these are the only relevant columns? That is, you simplified the data for posting; did you also simplify the query? Are there some other conditions or joins that occur in your real query, but you didn't psot here, because you didn't think they had anything to do with the problem? Maybe they do, after all.
I really need to see the problem before I can fix it.