Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL ServerBase de Dados SQL do AzureInstância Gerida do Azure SQLAzure Synapse Analytics
Uma aplicação ODBC tem três opções para obter dados de resultados.
A primeira opção baseia-se no SQLBindCol. Antes de buscar o conjunto de resultados, a aplicação usa o SQLBindCol para associar cada coluna do conjunto de resultados a uma variável do programa. Depois de as colunas terem sido atribuídas, o driver transfere os dados da linha atual para as variáveis ligadas às colunas do conjunto de resultados cada vez que a aplicação chama SQLFetch ou SQLFetchScroll. O driver trata das conversões de dados se o conjunto de resultados, a coluna e a variável do programa tiverem tipos de dados diferentes. Se a aplicação tiver SQL_ATTR_ROW_ARRAY_SIZE conjunto maior que 1, pode associar colunas de resultados a arrays de variáveis, que serão todas preenchidas em cada chamada ao SQLFetchScroll.
A segunda opção baseia-se no SQLGetData. A aplicação não utiliza SQLBindCol para associar colunas do conjunto de resultados a variáveis de programa. Após cada chamada ao SQLFetch, a aplicação chama o SQLGetData uma vez por cada coluna do conjunto de resultados. O SQLGetData instrui o driver a transferir dados de uma coluna específica do conjunto de resultados para uma variável de programa específica e especifica os tipos de dados da coluna e da variável. Isto permite ao driver converter dados se a coluna de resultado e a variável de programa tiverem tipos de dados diferentes. As colunas de texto, ntext e imagem são tipicamente demasiado grandes para caber numa variável de programa, mas ainda podem ser recuperadas usando SQLGetData. Se os dados de texto, ntext ou imagem na coluna de resultados forem maiores do que a variável do programa, SQLGetData devolve SQL_SUCCESS_WITH_INFO e SQLSTATE 01004 (dados de string, truncado à direita). Chamadas sucessivas ao SQLGetData retornam fragmentos sucessivos dos dados de texto ou imagem . Quando se atinge o fim dos dados, o SQLGetData devolve SQL_SUCCESS. Cada busca devolve um conjunto de linhas, ou conjunto de linhas, se SQL_ATTR_ROW_ARRAY_SIZE for maior que 1. Antes de usar SQLGetData, deve primeiro usar SQLSetPos para especificar uma linha específica dentro do conjunto de linhas como a linha atual.
A terceira opção é usar uma combinação de SQLBindCol e SQLGetData. Uma aplicação poderia, por exemplo, vincular as primeiras dez colunas de um conjunto de resultados e depois, em cada obtição, chamar SQLGetData três vezes para recuperar os dados de três colunas não vinculadas. Isto seria normalmente usado quando um conjunto de resultados contém uma ou mais colunas de texto ou imagem .
Dependendo das opções de cursor definidas para o conjunto de resultados, uma aplicação pode também usar as opções de scroll do SQLFetchScroll para percorrer o conjunto de resultados.
O uso excessivo do SQLBindCol para associar uma coluna de conjunto de resultados a uma variável de programa é dispendioso porque o SQLBindCol faz com que um driver ODBC aloque memória. Quando associa uma coluna de resultado a uma variável, essa ligação mantém-se ativa até que chame SQLFreeHandle para libertar o handle da instrução ou chame SQLFreeStmt com fOption definido para SQL_UNBIND. As ligações não são automaticamente desfeitas quando a instrução está concluída.
Esta lógica permite-lhe executar eficazmente a mesma instrução SELECT várias vezes com parâmetros diferentes. Como o conjunto de resultados mantém a mesma estrutura, podes associar o conjunto de resultados uma vez, processar todas as instruções SELECT e depois chamar SQLFreeStmt com fOption definido para SQL_UNBIND após a última execução. Não deve chamar o SQLBindCol para associar as colunas num conjunto de resultados sem antes chamar o SQLFreeStmt com o fOption definido para SQL_UNBIND para libertar quaisquer ligações anteriores.
Ao usar SQLBindCol, pode fazer binding linha a linha ou a coluna. A encadernação por linhas é um pouco mais rápida do que a encadernação por coluna.
Pode usar SQLGetData para recuperar dados coluna a coluna em vez de atribuir colunas ao conjunto de resultados usando SQLBindCol. Se um conjunto de resultados contiver apenas algumas linhas, usar SQLGetData em vez de SQLBindCol é mais rápido; caso contrário, o SQLBindCol oferece o melhor desempenho. Se não colocares sempre os dados no mesmo conjunto de variáveis, deves usar SQLGetData em vez de estares sempre a reassociar. Só podes usar SQLGetData em colunas que estão na lista select depois de todas as colunas estarem associadas com SQLBindCol. A coluna também deve aparecer após quaisquer colunas em que já tenha usado SQLGetData.
As funções ODBC que lidam com o movimento de dados para dentro ou fora de variáveis de programa, como SQLGetData, SQLBindCol e SQLBindParameter, suportam conversão implícita de tipos de dados. Por exemplo, se uma aplicação atribuir uma coluna inteira a uma variável de programa de cadeia de caracteres, o driver converte automaticamente os dados de inteiro para carácter antes de os colocar na variável de programa.
A conversão de dados nas aplicações deve ser minimizada. A menos que seja necessária conversão de dados para o processamento realizado pela aplicação, as aplicações devem vincular colunas e parâmetros a variáveis de programa do mesmo tipo de dado. Se os dados tiverem de ser convertidos de um tipo para outro, no entanto, é mais eficiente que o driver faça a conversão do que fazê-la na aplicação. O driver ODBC do SQL Server Native Client normalmente transfere dados diretamente dos buffers de rede para as variáveis da aplicação. Pedir ao driver para fazer a conversão de dados obriga-o a armazenar os dados em buffer e a usar ciclos de CPU para converter os dados.
As variáveis de programa devem ser suficientemente grandes para armazenar dados transferidos de uma coluna, exceto para texto, ntext e dados de imagem . Se uma aplicação tentar recuperar dados do conjunto de resultados e colocá-los numa variável demasiado pequena para os armazenar, o driver gera um aviso. Isto obriga o driver a alocar memória para a mensagem, e tanto o driver como a aplicação têm de passar ciclos de CPU a processar a mensagem e a tratar os erros. A aplicação deve alocar uma variável suficientemente grande para conter os dados a recuperar ou usar a função SUBSTRING na lista de seleção para reduzir o tamanho da coluna no conjunto de resultados.
Deve ter-se cuidado ao usar SQL_C_DEFAULT para especificar o tipo da variável C. SQL_C_DEFAULT especifica que o tipo da variável C corresponde ao tipo de dados SQL da coluna ou parâmetro. Se SQL_C_DEFAULT for especificado para uma coluna ntext, nchar ou nvarchar , os dados Unicode são devolvidos à aplicação. Isto pode causar vários problemas se a aplicação não tiver sido programada para lidar com dados Unicode. Os mesmos tipos de problemas podem ocorrer com o tipo de dado de identificador único (SQL_GUID).
os dados de texto, ntext e imagem são tipicamente demasiado grandes para caber numa única variável de programa, e normalmente são processados com SQLGetData em vez de SQLBindCol. Ao usar cursores de servidor, o driver ODBC do SQL Server Native Client está otimizado para não transmitir os dados de texto não encadernado, ntext ou colunas de imagem no momento em que a linha é recolhida. Os dados de texto, ntext ou imagem não são realmente recuperados do servidor até que a aplicação emita SQLGetData para a coluna.
Esta otimização pode ser aplicada a aplicações para que nenhum textoou ntext ou dados de imagem seja exibido enquanto o utilizador desliza para cima e para baixo no cursor. Depois de o utilizador selecionar uma linha, a aplicação pode chamar SQLGetData para recuperar os dados de texto, ntext ou imagem . Isto poupa a transmissão do texto, ntext ou dados de imagem para qualquer uma das linhas que o utilizador não selecione e pode poupar a transmissão de grandes quantidades de dados.