2010-12-20 2 views
0

MS Access에서 전체 외부 조인을 시뮬레이트하고 다음과 같은 결과를 결합한 쿼리를 만들었습니다.MS Access SQL : UNION ALL과 LEFT JOIN을 결합 할 때의 문제

SELECT NZ(estimates.employee_id, actuals.employee_id) AS employee_id 
, NZ(estimates.a_date, actuals.a_date) AS a_date 
, estimates.estimated_hours 
, actuals.actual_hours 
FROM (SELECT * 
     FROM estimates 
     LEFT JOIN actuals ON estimates.employee_id = actuals.employee_id 
     AND estimates.a_date = actuals.a_date 
     UNION ALL 
     SELECT * 
     FROM estimates 
     RIGHT JOIN actuals ON estimates.employee_id = actuals.employee_id 
     AND estimates.a_date = actuals.a_date 
     WHERE estimates.employee_id IS NULL 
     OR estimates.a_date IS NULL) AS qFullJoinEstimatesActuals 

이 쿼리를 개체로 저장했습니다 (qEstimatesAndActuals라고 부름). 내 목표는 LEFT JOIN qEstimatesAnduals를 다른 테이블로 조인하는 것입니다. 다음과 같은 :

SELECT * 
FROM qJoinedTable 
LEFT JOIN (SELECT * 
      FROM labor_rates) AS rates 
ON qJoinedTable.employee_id = rates.employee_id 
    AND qJoinedTable.a_date BETWEEN rates.begin_date AND rates.end_date 

MS Access는 구문을 허용하고 쿼리를 실행하지만 결과 집합 내에 명확한 결과는 생략합니다. 날짜 형식이 어떻게 든 사라 졌다면 begin_date 및 end_date 주위에 FORMAT을 배치하여 짧은 날짜로 해석하도록합니다. 이상하게도이 결과는 다른 결과를 낳았지만 결과가 누락되어서는 안됩니다.

UNION ALL 결과 집합 LEFT JOIN 수없는 방식으로 쿼리를 수행하는 경우 궁금합니다. 누구든지 이것에 대한 생각이나 아이디어가 있습니까? 최종 목표를 달성 할 수있는 더 좋은 방법이 있습니까?

답변

0

날짜를 둘러싼 이상한 행동과 일치하여이 문제는 qFullJoinEstimatesActuals에서 날짜를 선택하기 위해 NZ를 사용하는 것과 관련이있는 것으로 나타났습니다. NZ를 사용하면 데이터 유형이 모호한 것처럼 보입니다. 이와 같이, 내 게시물의 예에서 다음 행 오류 발생 :

a_date의 모호한 데이터 유형에 rates.begin_date하는 a_date 비교할 때 잘못된 결과를 생성하는 운영자와 rates.end_date간에 발생
, NZ(estimates.a_date, actuals.a_date) AS a_date 

LEFT JOIN. 내가 사용의 중복성을 제거하는 구문을 수정하지만

, CDate(NZ(estimates.a_date, actuals.a_date)) AS a_date 
+0

나는 또한 Nz()로 리턴 타입을 신뢰할 수 없다는 것에 좌절감을 나타냈다.하지만 정의에 따르면, 언젠가 적어도 언젠가는 널 (null)이 될 것으로 기대하고있다. 반환 형식 또는 소스 데이터에 대한 메타 데이터를 검사하십시오. 그래서, 당신 스스로 그것을해야합니다. 즉, 인덱스를 사용할 수 없기 때문에 Nz() 표현식에 조인하면 문제가되는 것입니다. –

+0

이 기사는 합리적인 UNION ALL에 기반한 것입니다. 당신은 오직 하나만 가지고 있습니다. 어떻게 모든 결과를 얻을 수 있습니까? – IamIC

+0

@ David-W-Fenton 당연히 말이됩니다. 디자인에 관해서는 다른 제안이 있습니까? 약간의 단순화와 함께, (1) employee_id, week_end_date, 및 projected_hours가있는 견적 테이블과 (2) employee_id, week_end_date 및 actual_hours가있는 실제 테이블. 예상대로 일하는 직원이있을 수 있지만 그렇지 않은 직원이있을 수 있습니다. 마찬가지로, 일할 것으로 예상되지 않았지만 그렇게 할 직원이있을 수 있습니다. 목표 : employee_id, week_end_date, projected_hours, actual_hours를 쿼리 가능한 단일 객체로 가져옵니다. 예 : 001, 9/26/2010, 0, 10 – Adam

0

정확히 수행하는 방법은 here입니다.

당신은 INNER JOIN .... UNION ALL 단계를 놓치고 있습니다.

+0

당신이 전체의 기초로 사용되었다 언급 한 기사는 (가입 : 다음과 같은 문제는 뉴질랜드 함수의 결과를 주조 유형에 의해 해결되었다 INNER JOIN - 언급 된 기사에 댓글을 달았던 사람들 중 일부가 할 수있는 것처럼). 그러나 FULL JOIN을 생성하는 구문은 내가 가지고있는 문제가 아닌 * 문제입니다. 위에서 설명한 문제는 FULL JOIN (자체적으로 작동)의 결과 집합이 LEFT JOIN과 결합 될 때 생성되는 결과 집합을 의미합니다. – Adam

+0

기사에서 벤 다이어그램을보십시오.이 기사가 작성되면 작성자는 Set 1 (INNER JOIN), Set 2 (WHERE 절을 사용하여 LEFT JOIN을 사용하여 Set 1 결과 제거), Set 3 (WHERE 절을 사용하여 RIGHT JOIN을 사용하여 Set 1 결과) 두 개의 UNION ALL을 사용하여 결합합니다. 이것은 두 개의 쿼리를 사용하여 더 간단하게 수행 할 수 있습니다. 첫 번째 세트는 세트 1과 2 (LEFT JOIN *없이 WHERE 절을 사용하여 세트 1 결과 제거)를 얻고 두 번째는 세트 3을 얻으려고합니다 (WHERE 절을 사용하여 RIGHT JOIN을 제거 1 개의 결과를 설정) 하나의 UNION ALL을 사용하여 결합하십시오. – Adam

+0

@Adam 감사합니다. 호기심에서 SQL Server를 사용하는 것이 어떻습니까? – IamIC

1

쿼리의 각 부분을 고유 한 액세스 쿼리 개체 (예 :

SELECT * 
    FROM estimates 
    LEFT JOIN actuals ON estimates.employee_id = actuals.employee_id 
    AND estimates.a_date = actuals.a_date 

SELECT * 
    FROM estimates 
    RIGHT JOIN actuals ON estimates.employee_id = actuals.employee_id 
    AND estimates.a_date = actuals.a_date 
    WHERE estimates.employee_id IS NULL 
    OR estimates.a_date IS NULL 

이 qryTwo

SELECT * FROM qryOne 
UNION ALL 
SELECT * FROM qryTwo 

이 qryFullJoinEstimatesActuals겠습니까겠습니까 qryOne 것, 그리고 마지막으로

SELECT NZ(estimates.employee_id, actuals.employee_id) AS employee_id 
, NZ(estimates.a_date, actuals.a_date) AS a_date 
, estimates.estimated_hours 
, actuals.actual_hours 
FROM qryFullJoinEstimatesActuals 

내가 발견 한 것을하지 않는 구조 복잡한 접근 S에서 일한다. QL 문은 개별 쿼리 개체로 분해되고 단계별로 다시 어셈블 된 경우 제대로 작동합니다. 또한 쿼리의 각 부분을 개별적으로 테스트 할 수 있습니다. 이렇게하면 필요한 것으로 판명되면 해결 방법을 찾는 데 도움이됩니다.

+0

팁 주셔서 감사. 이것이 근본적인 문제는 아니지만 나중에 문제가되었던 또 다른 무관 한 오류를 넘어서서 우연히 발견되어 (b) 문제의 원인을 파악하는 데 도움이되었습니다. – Adam

관련 문제