기본 콘텐츠로 건너뛰기

펌 - DBNull VS null

원본 : http://resisa.tistory.com/14

이전 프로그램에서 쿼리를 날린 후에 결과 값을 도메인 객체로 컨버트 해줄 때 결과집합이 DataSet이든 DataReader이든지 NULL값 때문에 삼항연산자를 사용하여 다음과 같은 작업을 했었다.

(프로퍼티의 타입은 string이라고 가정하자.)

 도메인.프로퍼티 = 결과집합["해당컬럼"] != null ? 결과집합["해당컬럼"].ToString() : "";

일단 DBNull과 null은 과연 같은 값일까? 이름부터 다르기 때문에 다른 값으로 취급이 된다.
그러면 위의 결과집합["해당컬럼"]은 DBNull일까? null일까?
DB에 쿼리를 날린 것이기 때문에 DBNull로 취급이 된다고 생각하자. 지금까지 저 구문이 이상하다고 느끼지 못했는데 어느순간에 의심이 들었다. DB에는 NULL이 들어가 있음에도 false일 때의 루틴이 아닌 true때의 루틴을 실행하는 것 같았다. 그리고 몇가지 테스트를 통하여 결과집합["해당컬럼"]은 null이 아닌 DBNull임을 알 수 있었다.
그럼 위의 구문을 다음과 같이 바꿔보자.

 도메인.프로퍼티 = 결과집합["해당컬럼"] !=  DBNull.Value ? 결과집합["해당컬럼"].ToString() : "";

이제 내가 원하는 루틴으로 프로그램이 실행되는 것을 알 수 있다.
그러다가 다른 프로그램에서 도메인으로 컨버트 하는 것을 보았다.

 도메인.프로퍼티 = 결과집합["해당컬럼"].ToString();

훨씬 더 심플하다. 애초에 결과집합["해당컬럼"]이 null일 꺼란 생각때문에 .ToString()이 예외를 던질꺼라고 생각하였다. (Null Exception) 하지만 예외는 발생하지 않았고 DBNull.Value.ToString()은 바로 빈스트링("")이다. 여기서 한가지 주의할 점이 있다. 결과집합["해당컬럼"]이 null일꺼라고 왜 생각한것일까? DB에서 받아온 값이 null일 때가 있는데 결과집합이 아닌 스칼라(단일값)로 값을 받아올 때이다. 스칼라 값에 null이 들어가 있을 경우에는 DBNull로 취급이 된다. 좀 더 이해를 하기 쉽게 하기 위해서 다음 그림을 보자.

 그림1
 그림2

그림1의 경우에는 GRADE란 컬럼에 값이 null이여서 스칼라값으로 받아온 값이 DBNull이 된다. 그림2의 경우는 데이터가 없는 테이블에 조회한 경우 또는 WHERE절 조건을 만족하는 값이 없을 경우에 해당한다. 바로 이럴 경우가 스칼라값이 null이 되는 경우이다. (※ 여기서 결과집합도 스칼라값과 마찬가지로 데이터가 없는 테이블에 조회한 경우에(그림2) 혹 null을 반환해주지 않을까 해서 테스트 해본결과 Count=0인 DataSet(결과집합)를 반환해준다.)

보통 string 타입이 가장 많기 때문에 마지막에 입력한대로 하는게 가장 심플해보인다. 하지만 DateTime타입에는 NULL값이 들어갈 수 있기 때문에 컨버트를 해줄때 DBNull인지 체크를 하고 컨버트를 해줘야 한다. 이 마저도 테이블을 처음에 정의할 때 NULL이 들어가지 않게 해준다면 무조건 DateTime으로 컨버트 해줄수도 있겠다.

댓글

이 블로그의 인기 게시물

80040154 오류로 인해 CLSID가 {xxxx-...}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

원문보기 .NET 으로 만든 응용프로그램에서 com 객체를 호출한 경우 Windows7 64bit 에서 제목과 같은 에러가 발생했다. Win32 COM 과 .NET 프로그램간의 호환성 때문에 생긴 문제였다. 원인은 .NET 실행시 JIT 컴파일러에 의해 최적화된 기계어로 변환되기 때문.. Win32 COM은 컴파일시.. Win32 COM에 맞춰 빌드 속성에서 하위버전으로 맞춰 컴파일을 다시하는 방법도 있지만 메인 프로젝트가 .NET이라면 참조되는 모든 프로젝트를 다 바꿔야할 노릇.. 또 다른 방법은 COM+를 이용하여 독립적으로 만드는 것이다. 분리시키는 방법은 아래 주소해서 확인할 수 있다. http://support.microsoft.com/kb/281335 나의 경우는 Win32 COM DLL을 64비트 .NET 프로그램에서 참조하니 COM 객체를 제대로 호출하지 못하였습니다. 그래서 .NET 프로그램의 Target Machine을 x86으로 설정하니 제대로 COM 객체를 호출하였습니다.

[Pyinstaller] 실행 파일 관리자 권한 획득하기

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 Python 코드에서 관리자 권한을 요청하는 코드를 넣으려고 했는데, 실제로 Stackoverflow를 찾아보면 이런 내용이 나옵니다. 프로그램이 관리자 권한으로 실행되지 않았다면 관리자 권한으로 다시 프로그램을 실행시키는 코드입니다. import os import sys import win32com.shell.shell as shell ASADMIN = 'asadmin' if sys.argv[-1] != ASADMIN: script = os.path.abspath(sys.argv[0]) params = ' '.join([script] + sys.argv[1:] + [ASADMIN]) shell.ShellExecuteEx(lpVerb='runas', lpFile=sys.executable, lpParameters=params) sys.exit(0) 하지만 개인적으로 이런 방식은 마음에 들지 않았고 조금 더 찾아보니 Pyinstaller로 exe 파일을 만들 때 옵션을 설정하여 관리자 권한을 요청하도록 할 수 있다고 합니다. --uac-admin을 옵션에 추가하면 프로그램 실행 시 관리자 권한을 요청할 수 있습니다. pyinstaller.exe --uac-admin sample.py 하지만 안타깝게도 이 방식은 원하는 대로 동작하지 않았습니다. 마지막으로 manifest 파일을 이용하여 시도해보았습니다. spec 파일을 이용하여 pyinstaller로 빌드하면 <실행 파일 이름>.manifest 라는 파일이 생성됩니다. 파일에서 아랫부분을 찾아볼 수 있습니다. <security> <re

초간단 프로그램 락 걸기

프로그램에 락을 걸 일이 생겨났다. 하드웨어 락을 걸면 쉬울텐데 그 정도는 아니고 프로그램의 실행 날짜를 제한 해 달라고 한다. 그래서 파일(license.lic)을 가지고 락을 걸리고 결정을 했다. 요구 사항은 아래와 같다. 1. license.lic 파일이 없으면 프로그램을 실행 할수 없게 한다. 2. 지정한 날짜를 넘어서는 프로그램을 실행 할수 없게 한다. 3. 사용자가 시스템 날짜를 되돌렸을때 인식하여 프로그램을 실행 할수 없게 한다. 음.... 1.번 문제는 사용자가 프로그램을 실행하기 위해서 license.lic 파일을 받아야만 한다. license.lic 파일에는 최근 실행 날짜/종료날짜 이런식으로 적도록 한다.(물론 내용은 암호화 한다.) 최근 실행날짜는 프로그램이 실행때마다 업데이트 하도록 하고 시스템 날짜와 비교하여 시스템 날짜가 최근 실행 날짜보다 이전의 날짜면 시스템 날짜를 되돌렸다고 인식하도록 한다.(3.번 문제 해결) 시스템 날짜와 종료 날짜를 비교하여 시스템 날짜가 종료 날짜를 넘으면 프로그램을 실행 할수 없도록 한다.(2.번 문제 해결)