문을 실행 하기 전에 응용 프로그램은 바인딩된 배열에서 각 데이터 요소의 값을 설정 합니다. 명령문이 실행되면 드라이버는 하나의 네트워크 왕복을 사용하여 전체 배열 내용을 처리하려고 시도합니다. 예를 들어 다음 예제인 사례 1과 사례 2를 비교해 보겠습니다. 특정 데이터 형식을 검색하고 보내는 데 비용이 많이 들 수 있습니다. 스키마를 디자인할 때 가장 효율적으로 처리할 수 있는 데이터 형식을 선택합니다. 예를 들어 정수 데이터는 부동 지점 데이터보다 더 빠르게 처리됩니다. 부동 지점 데이터는 일반적으로 압축된 형식으로 내부 데이터베이스별 형식에 따라 정의됩니다. 와이어 프로토콜에 의해 처리될 수 있도록 데이터를 압축해제하고 다른 형식으로 변환해야 합니다. 많은 ODBC 드라이버를 사용하면 SQL_MAX_LENGTH 특성을 지원하여 네트워크를 통해 검색되는 데이터의 양을 제한할 수 있습니다. 이 특성을 사용하면 드라이버가 x바이트의 데이터만 클라이언트와 관련이 있음을 데이터베이스 서버에 통신할 수 있습니다. 서버는 모든 결과 열에 대해 첫 번째 x 바이트의 데이터만 전송하여 응답합니다.
이러한 최적화는 네트워크 트래픽을 크게 줄이고 클라이언트 성능을 향상시킵니다. 앞의 예제에서는 하나의 행만 반환했지만 결과 집합에서 100개의 행이 반환되는 경우성능 이 향상이 상당합니다. SQLGetTypeInfo는 많은 드라이버가 지원되는 데이터 형식에 대한 정확한 정보를 얻기 위해 서버를 쿼리해야 하기 때문에 성능이 비싼 ODBC 함수로 나열됩니다(예: 사용자 정의 형식과 같은 동적 형식을 찾으려면). 이 예제에서 응용 프로그램은 정보가 요청된 개체에 대한 빈번한 정보를 제공합니다. 세 개의 „고객“ 테이블이 결과 집합에서 반환되었다고 가정합니다: 사용자가 소유한 첫 번째 테이블, 영업 부서가 소유한 두 번째 테이블, 세 번째 테이블은 경영진이 만든 보기입니다. 최종 사용자에게 선택할 테이블을 명확하지 않을 수 있습니다. 응용 프로그램에서 SQLTables 호출에서 OwnerName 인수를 지정한 경우 하나의 테이블만 반환되고 성능이 향상됩니다. 하나의 결과 행만 반환하는 데 필요한 네트워크 트래픽이 적고 원치 않는 행이 데이터베이스에서 필터링됩니다. 또한 TableType 인수가 제공된 경우 다음과 같이 세 개의 쿼리 유니온에서 단일 Select 문으로 서버로 전송된 SQL을 최적화할 수 있습니다. 실행하기 전에 모든 준비를 완료할 수 있도록 두 개의 서로 다른 stmts를 사용합니다. 이제 대부분의 ODBC 드라이버는 앞으로 커서에 대해서만 SQLExtendedFetch를 지원합니다.
그러나 대부분의 ODBC 응용 프로그램은 SQLFetch를 사용하여 데이터를 검색합니다. SQLFetch 대신 SQLExtendedFetch를 사용하는 이전 예제를 다시 고려하십시오: 가능한 SQL 문이 많기 때문에 가능한 문제 조건의 범위가 넓습니다 – 특히 클래스 22000 (데이터 예외) 및 클래스 23000의 SQLSTATE 오류를 참조하십시오. SQL/CLI 진단에 대한 당사의 장에서 무결성 제약 조건 위반)을 참조하십시오. 또한 경고 및 „데이터 없음“ 조건(예: UPDATE Table_1 SET column_1 = 0의 실행) TABLE_1에 행이 없는 경우 SQLSTATE 02000 „데이터를 찾을 수 없음“이 발생합니다. 응용 프로그램은 SQLSpecialColumns/SQL_BEST_ROWID를 호출하여 지정된 레코드를 식별하는 최적의 열 집합(의사 열일 수 있음)을 검색해야 합니다. 대부분의 데이터베이스는 테이블 정의의 사용자가 명시적으로 정의하지 는 않지만 모든 테이블의 „숨겨진“ 열(예: ROWID 및 TID)인 특수 열을 지원합니다. 이러한 의사 열은 일반적으로 레코드의 정확한 위치를 가리키기 때문에 데이터에 가장 빠르게 액세스할 수 있습니다.
