테이블을 두개를 만들었어여

   고객                       테잎
------------         -------------
고객코드                  테잎코드
고객이름                  테잎이름
주민번호                  대여일자
주소                        반납일자
전화번호                  상 태(반납/미반납)


일단 Table 구성이 잘못되어진 것 같군여..
위의 내용은 아래처럼 설계되어야 합니다..

   고객                       테잎
------------         -------------
고객코드                  고객코드
고객이름                  테잎코드
주민번호                  테잎이름
주소                        대여일자
전화번호                  반납일자
                              상 태(반납/미반납)


이렇게 하면,
Query상으로 해결이 가능해 집니다..

Select 고객이름, 테잎이름, 대여일자, 반납일자, 상태
  from  고객,
           테잎
where 고객.고객코드 = 테잎.고객코드

하면, 해결 될 것입니다..
답이 되셨길 바랍니다..

학교에서 델파이를 배우는데 매력이 느껴져서 독학으로 공부하거든여...
DB를 배운게 군대가기전이라 제대후 바로 복학하니... --;
암것도 모르겠네여
모두 감솨하구
델파이 화이팅입니다. 화이팅

안녕하세요.

코딩이전에 설계가 먼저 선행되어야 합니다.
설계는 하시고자 하는 의도를 전혀 반영하고 있지 않네요.
먼저 코딩으로 해결하려는 습관을 잠시 멈추시고 현실세계를 어떻게
시스템적으로 모델링해야할까를 고민해야 할듯 합니다.

님의 지금 두 테이블은 고객, 그리고 테입 테이블 입니다만,
이 두 테이블은 단지 기초사항만을 가지고 있을 뿐입니다.
이러한 기초정보를 담는 테이블에 실제 고객과 테입의 대여/반납관계를
기록하려는것은 매우 비바람직한 테이블 설계입니다.
이렇게 되면, 단순해서 코딩하기 좋을지 모르지만,
결론적으로 다양한 실세계의 대여/반납 관계를 구현하지 못합니다.

고객, 테입 두 테이블은 그냥 기본적인 정보를 가지고 있구여,
이 두 테이블의 거래관계를 나타내는 또 다른 중간테이블이 있고
그 곳에서 현실거래를 반영하는것이 좋을듯  합니다.
이렇게 되면 님이 기존에 했던 코딩들이 전부 바뀌어야 할겁니다.
설계가 흔들렸으니까요.

그래서, 그냥 이 상태에서 하신다면, 고객테이블의 주키영역에
테입테이블의 테입코드를 추가하는 방법입니다만,
흠... 이것역시 매우 비바람직한 설계구현입니다. ^^;;
그렇지만 시간이 없으니 어쩝니까... ^^;;
달랑 두 테이블로 그러한 현실거래를 구현하려는것은
무리라 생각됩니다. 감히 실무적 시각에서 본다면.^^;

뭐라 이야기를 더 이상 못드려서 죄송합니다.
코딩이전에 설계가 현실세계를 반영하지 못하니, 코딩하면 할수록
계속 테이블이 변경되고 그에따른 소스는 비대해지고 복잡해 질것 같네요 ^^;