데이터 길이, 버퍼 길이 및 잘림

데이터 길이는 데이터 원본에 저장되지 않고 애플리케이션의 데이터 버퍼에 저장되기 때문에 데이터의 바이트 길이입니다. 이러한 구분은 데이터가 데이터 원본과는 다른 형식의 데이터 버퍼에 저장되기 때문에 중요합니다. 따라서 데이터 원본으로 전송되는 데이터의 경우 데이터 원본의 형식으로 변환하기 전에 데이터의 바이트 길이입니다. 데이터 원본에서 검색되는 데이터의 경우 데이터 버퍼의 형식으로 변환한 후 잘림이 수행되기 전에 데이터의 바이트 길이입니다.

정수 또는 날짜 구조와 같은 고정 길이 데이터의 경우 데이터의 바이트 길이는 항상 데이터 형식의 크기입니다. 일반적으로 애플리케이션은 데이터 형식의 크기인 데이터 버퍼를 할당합니다. 애플리케이션이 더 작은 버퍼를 할당하는 경우 드라이버는 데이터 버퍼가 데이터 형식의 크기라고 가정하고 더 작은 버퍼에 맞게 데이터를 자르지 않으므로 결과가 정의되지 않습니다. 애플리케이션이 더 큰 버퍼를 할당하는 경우 추가 공간은 사용되지 않습니다.

문자 또는 이진 데이터와 같은 가변 길이 데이터의 경우 데이터의 바이트 길이가 버퍼의 바이트 길이와 별개이고 종종 다르다는 것을 인식하는 것이 중요합니다. 이러한 두 길이의 관계는 버퍼 섹션에 설명되어 있습니다 . 데이터의 바이트 길이가 버퍼의 바이트 길이보다 크면 드라이버는 페치된 데이터를 버퍼의 바이트 길이로 잘라내고 SQLSTATE 01004(데이터가 잘린) SQL_SUCCESS_WITH_INFO 반환합니다. 그러나 반환된 바이트 길이는 신뢰할 수 없는 데이터의 길이입니다.

예를 들어 애플리케이션이 이진 데이터 버퍼에 대해 50바이트를 할당한다고 가정합니다. 드라이버에 반환할 10바이트의 이진 데이터가 있는 경우 버퍼에서 해당 10바이트를 반환합니다. 데이터의 바이트 길이는 10이고 버퍼의 바이트 길이는 50입니다. 드라이버에 반환할 60바이트의 이진 데이터가 있는 경우 데이터를 50바이트로 잘라내고 버퍼에서 해당 바이트를 반환하며 SQL_SUCCESS_WITH_INFO 반환합니다. 데이터의 바이트 길이는 60(잘림 전 길이)이며 버퍼의 바이트 길이는 여전히 50입니다.

잘리는 각 열에 대해 진단 레코드가 만들어집니다. 드라이버가 이러한 레코드를 만들고 애플리케이션이 레코드를 처리하는 데 시간이 걸리기 때문에 잘림으로 인해 성능이 저하될 수 있습니다. 일반적으로 애플리케이션은 긴 데이터로 작업할 때는 가능하지 않을 수 있지만 충분히 큰 버퍼를 할당하여 이 문제를 방지할 수 있습니다. 데이터 잘림이 발생하면 애플리케이션에서 더 큰 버퍼를 할당하고 데이터를 다시 래치할 수 있습니다. 이는 모든 경우에 해당되지 않습니다. SQLGetData에 대한 호출로 데이터를 가져오는 동안 잘림이 발생하는 경우 애플리케이션은 이미 반환된 데이터에 대해 SQLGetData를 호출할 필요가 없습니다. 자세한 내용은 긴 데이터 가져오기를 참조하세요.