맞춤

ODBC 애플리케이션의 맞춤 문제는 일반적으로 다른 애플리케이션과 다르지 않습니다. 즉, 대부분의 ODBC 애플리케이션에는 맞춤에 문제가 거의 없거나 전혀 없습니다. 주소를 정렬하지 않는 것에 대한 처벌은 하드웨어 및 운영 체제에 따라 다르며 약간의 성능 저하 또는 치명적인 런타임 오류만큼 심각할 수 있습니다. 따라서 ODBC 애플리케이션 및 특히 이식 가능한 ODBC 애플리케이션은 데이터를 올바르게 정렬하는 데 주의해야 합니다.

ODBC 애플리케이션에서 맞춤 문제가 발생하는 경우의 한 가지 예는 큰 메모리 블록을 할당하고 해당 메모리의 다른 부분을 결과 집합의 열에 바인딩하는 경우입니다. 이는 제네릭 애플리케이션이 런타임에 결과 집합의 모양을 확인하고 그에 따라 메모리를 할당하고 바인딩해야 하는 경우에 발생할 가능성이 높습니다.

예를 들어 애플리케이션이 사용자가 입력한 SELECT 문을 실행하고 이 문의 결과를 가져온다고 가정합니다. 프로그램이 작성될 때 이 결과 집합의 모양을 알 수 없으므로 애플리케이션은 결과 집합을 만든 후 각 열의 형식을 결정하고 그에 따라 메모리를 바인딩해야 합니다. 이 작업을 수행하는 가장 쉬운 방법은 큰 메모리 블록을 할당하고 해당 블록의 다른 주소를 각 열에 바인딩하는 것입니다. 열의 데이터에 액세스하기 위해 애플리케이션은 해당 열에 바인딩된 메모리를 캐스팅합니다.

다음 다이어그램에서는 샘플 결과 집합과 각 SQL 데이터 형식에 대한 기본 C 데이터 형식을 사용하여 메모리 블록을 바인딩하는 방법을 보여 있습니다. 각 "X"는 단일 바이트 메모리를 나타냅니다. (이 예제에서는 열에 바인딩된 데이터 버퍼만 보여 줍니다. 이 작업은 단순성을 위해 수행됩니다. 실제 코드에서는 길이/표시기 버퍼도 정렬해야 합니다.)

바인딩된 주소가 주소 배열에 저장되어 있다고 가정하면 애플리케이션은 다음 식을 사용하여 각 열에 바인딩된 메모리에 액세스합니다.

(SQLCHAR *)       Address[0]  
(SQLSMALLINT *)   Address[1]  
(SQLINTEGER *)    Address[2]  

두 번째 및 세 번째 열에 바인딩된 주소는 홀수 바이트에서 시작하며 세 번째 열에 바인딩된 주소는 SDWORD 크기인 4로 나눌 수 없습니다. 일부 컴퓨터에서는 문제가 되지 않습니다. 다른 사람에, 그것은 약간의 성능 페널티를 일으킬 것 이다; 여전히 다른 사용자에 대해 심각한 런타임 오류가 발생합니다. 더 나은 해결 방법은 각 바인딩된 주소를 자연 맞춤 경계에 맞추는 것입니다. UCHAR의 경우 1, SWORD의 경우 2, SDWORD의 경우 4라고 가정하면 다음 그림에 표시된 결과를 제공합니다. 여기서 "X"는 사용되는 메모리 바이트를 나타내고 "O"는 사용되지 않는 메모리 바이트를 나타냅니다.

이 솔루션은 애플리케이션의 메모리를 모두 사용하지는 않지만 맞춤 문제가 발생하지는 않습니다. 안타깝게도 각 열은 해당 형식에 따라 개별적으로 정렬되어야 하므로 이 솔루션을 구현하려면 상당한 양의 코드가 필요합니다. 더 간단한 해결 방법은 다음 그림에 표시된 예제에서 4인 가장 큰 맞춤 경계의 크기에 모든 열을 맞추는 것입니다.

이 솔루션은 더 큰 구멍을 남기지만 구현하는 코드는 비교적 간단하고 빠릅니다. 대부분의 경우 사용되지 않는 메모리에서 지불된 페널티를 상쇄합니다. 이 메서드를 사용하는 예제는 SQLBindCol 사용을 참조 하세요.