1. 부서번호 입력받아 삭제하는 저장프로시저 생성 + CallableStatement + 예외처리
문제) dept 테이블에서 부서번호를 입력받아서 부서를 삭제하는 up_deleteDept 저장 프로시저를 선언하고 CallableStatement 를 사용해서 부서를 삭제하는 코딩
( 조건 : 삭제할 부서가 없는 경우는 예외 처리를 할 수 있게 코딩 )
[ 저장 프로시저 ]
[ main ]
2. CallableStatement와 출력용 파라미터(커서) 사용하는 예제1
문제) emp테이블에서 deptno를 파라미터로 입력받아서 그 부서에 속해있는 사원 정보 반환하는 저장프로시저 생성(up_selectEmp) 후 Java에서 CallableStatement를 사용해서 출력 처리
> registerOutParameter -> 출력용 매개변수 타입 : oracle.jdbc.OracleTypes.파라미터타입
> 반환값을 cursor가 가지고 있어서 rs로 반환하지 않고 executeQuery만 실행하고 getObject로 값을 가져옴
> 결과물이 커서에 있기 때문에 ResultSet 형변환 후 rs에 담음
[ 저장 프로시저 생성 ]
[ main 및 printEmp 메서드 ]
3. CallableStatement와 출력용 파라미터 사용하는 예제2
문제) ID 중복 체크하기
> registerOutParameter -> 출력용 매개변수 타입 : oracle.jdbc.OracleTypes.파라미터타입
> 반환값을 출력용 파라미터가 가지고 있어서 rs로 반환하지 않고 executeQuery만 실행하고 getObject로 값을 가져옴
> 결과물이 출력용 파라미터에 있기 때문에 출력용 파라미터 자료형에 맞는 변수에 형변환 후에 담음
[ 저장 프로시저 ]
[ main ]
> OracleTypes를 NUMBER로 주었다가 BigDecimal이라는 에러가 발생해서 INTEGER로 바꿔주니 잘 실행이 되었다.
4. CallableStatement와 출력용 파라미터 사용하는 예제3
문제) 로그인 체크하기
[ 저장 프로시저 ]
[ main ]
5. 리플렉션(reflection)
- 반사, 반영이라는 뜻
- ResultSet 결과물에 대한 정보를 추출해서 사용할 수 있는 기술
ㄴ ResultSet으로부터 어떤 컬럼이 어떤 자료형을 가지고 있는지 등등 정보를 얻어와서 사용하는 기술을 [리플렉션] 이라고 한다.
- 테이블명, 컬럼명은 바인딩 변수(?)를 사용할 수 없다.
아래 예시로...
SCOTT 계정이 소유하고 있는 테이블 목록을 보여주고 목록에 있는 테이블 중 하나를 입력 받아 ResultSetMetaData rsmd = rs.getMetaData(); 코딩을 한 뒤에 테이블의 컬럼 갯수, 자료형 등을 파악한 후 레코드를 가져오도록 하겠다.
[ main ]
ResultSetMetaData rsmd = rs.getMetaData();
> ResultSet에 있는 MetaDate를 ResultSetMetaData 객체에 담으면 컬럼 갯수, 컬럼명, 컬럼의 자료형, scale, 정밀도 등을 알 수 있다.
> getColumnCount() : 컬럼갯수
> getColumnName() : 컬럼명
> getColumnTypeName() : 컬럼의 자료형
> getColumnType() : 컬럼의 자료형을 숫자로 나타낸 것(2 NUMBER, 93 DATE, 12 VARCHAR2)
> getScale() : 실수라면 scale이 0보다 큼
> getPrecision() : 자료형의 정밀도(크기)
오늘로 JDBC 수업은 끝나고 Web을 배우게 되었다. 많이 배우지는 않았지만 환경설정과 역사에 대해서 정리한 글은 따로 작성하도록 하겠다.
'TIL > JDBC' 카테고리의 다른 글
[SIST] JDBC_days05_Java에서 트랜잭션 처리와 CallableStatement (0) | 2022.05.10 |
---|---|
[SIST] JDBC_days05_페이징 처리하기 (0) | 2022.05.10 |
[SIST] JDBC_days04 (0) | 2022.05.09 |
[SIST] JDBC_days03 (0) | 2022.05.05 |
[SIST] JDBC_days02 (0) | 2022.05.03 |