Esta anotação descreve como recuperar e enviar os ODBC SQL_LONGVARCHAR e SQL_LONGVARBINARY tipos de dados usando as classes de banco de dados MFC.
Suporte a visão geral de Varchar Long/Varbinary
Os tipos de dados ODBC SQL_LONG_VARCHAR e SQL_LONGBINARY (referidos aqui como colunas de dados longas) podem conter grandes quantidades de dados. Há 3 maneiras que você pode manipular esses dados:
Colunas de dados longos não há suporte para parâmetros para uma consulta. Só há suporte para outputColumns.
Vinculando uma longa coluna de dados a um CString/CByteArray
Vantagens:
Essa abordagem é simple de entender e trabalhar com classes de familiares. O framework fornece suporte de CFormView para CString com DDX_Text. Você tem lotes de Cadeia de caracteres geral ou funcionalidade de coleção com o CString e CByteArray classes, e você pode controlar a quantidade de memória alocada localmente para armazenar o valor de dados. O quadro mantém uma cópia velha do campo dados durante a Editar ou AddNew função chamadas e o quadro pode detectar automaticamente as alterações dos dados por você.
&Notanbsp; Desde CString é projetado para trabalhar em dados de caracteres e CByteArray para trabalhar em dados binários, é recomendável que você posta os dados de caracteres (SQL_LONGVARCHAR) em CStringe os dados binários (SQL_LONGVARBINARY) CByteArray.
As funções RFX para CString e CByteArray tem um argumento adicional que permite que você substituir o tamanho de padrão de memória alocada para armazenar o valor recuperado para a coluna de dados. Observe o argumento de nMaxLength nas seguintes declarações de função:
privatevoid AFXAPI RFX_Text(CFieldExchange* pFX, const char *szName,
nbsp; CString & value, int nMaxLength = 255, int nColumnType =
SQL_VARCHAR);
privatevoid AFXAPI RFX_Binary(CFieldExchange* pFX, const char *szName, CByteArray& value,int nMaxLength = 255)
Se você recuperar uma coluna de dados longos em um CString ou CByteArray, o máximo retornado a quantidade de dados é, por padrão, 255 bytes. Qualquer coisa além disso é ignorada. Neste caso, o quadro irá lançar a exceção AFX_SQL_ERROR_DATA_TRUNCATED. Felizmente, você pode aumentar explicitamente nMaxLength para valores maiores, até MAXINT.
ClassWizard irá ligar um SQL_LONGVARCHAR para um CStringou um SQL_LONGVARBINARY para um CByteArray para você. Se desejar alocar mais de 255 bytes no qual você recupera sua coluna de dados long, em seguida, você pode fornecer um valor explícito para nMaxLength.
Quando uma coluna de dados long é ligada a um CString ou CByteArray, atualizando o campo funciona exatamente o mesmo como quando ele é ligado a um SQL_VARCHAR ouVARBINARYde SQL_. Durante a Editar, o valor de dados é armazenado em cache afastado e mais tarde em relação ao Update é chamado para detectar alterações ao valor de dados e definir adequadamente os sujo e Null valores para a coluna.
Vinculando uma longa coluna de dados para um CLongBinary
Se sua coluna dados longos pode conter mais MAXINT bytes de dados, você provavelmente deve considerar recuperá-lo em um CLongBinary.
Vantagens:
Isso recupera uma coluna de dados inteiro longo - até a memória disponível.
Desvantagens:
Os dados são mantidos na memória. Esta abordagem também é proibitivamente cara para quantidades muito grandes de dados. Você deve chamar SetFieldDirty para o membro de dados ligado garantir que o campo é incluído em uma operação de atualização.
Se você recuperar dados longos colunas em um CLongBinary, as classes de banco de dados irão verificar o tamanho total da coluna de dados long, em seguida, alocar um segmento de memória HGLOBAL suficientemente grande para a armazenar o valor de dados inteiro. As classes de banco de dados, em seguida, recuperam o valor de dados inteiro em alocado HGLOBAL.
Se a fonte de dados não é possível retornar o tamanho esperado da coluna de dados longos, o framework lançará a exceção AAFX_SQL_ERROR_SQL_NO_TOTAL. Se a tentativa de alocar HGLOBAL falhar, uma exceção de memória padrão é lançada.
ClassWizard irá ligar um SQL_LONGVARCHAR ou SQL_LONGVARBINARY para um CLongBinary para você. Selecione CLongBinary como o tipo de variável na caixa de diálogo Adicionar membro variável. ClassWizard irá, em seguida, adicionar uma chamada RFX_LongBinary para a chamada DoFieldExchange e incrementar o número total de campos ligados.
Para atualizar valores de coluna de dados longos, primeiro certifique-se de alocado HGLOBAL é grande o suficiente para armazenar seus dados novos por chamado :: GlobalSize no membro m_hData de CLongBinary. Se for muito pequeno, liberar HGLOBAL e alocar um tamanho apropriado. Em seguida, defina m_dwDataLength para refletir o novo tamanho.
Caso contrário, se m_dwDataLength for maior que o tamanho dos dados que você está substituindo, você pode livre e realocar HGLOBALou deixá-lo atribuídas. Certifique-se de indicar o número de bytes realmente utilizados em m_dwDataLength.
Como atualizar um CLongBinary funciona
Não é necessário entender como funciona a atualização um CLongBinary , mas pode ser útil como um exemplo sobre como enviar valores de dados longos para uma fonte de dados, se você escolher este terceiro método, descrito a seguir.
&Notanbsp; Para um campo de CLongBinary para ser incluída em uma atualização, você deve explicitamente chamar SetFieldDirty para o campo. Se você fizer qualquer alteração a um campo, incluindo configuração seja Null, você deve chamar SetFieldDirty.
Ao atualizar um campo de CLongBinary , as classes de banco de dados usam mecanismo DATA_AT_EXEC do ODBC (consulte a documentação do ODBC SQLSetPosdo rgbValue argumento). Quando o quadro prepara a inserção ou instrução de atualização, em vez de apontar para o HGLOBAL que contém os dados, o endereço de CLongBinary é definida como o valor da coluna em vez disso, e o indicador de comprimento definido como SQL_DATA_AT_EXEC. Mais tarde, quando a instrução update é enviada para a fonte de dados, o SQLExecDirect retornará SQL_NEED_DATA. Isso alerta o quadro que o valor de parâmetro para esta coluna é realmente o endereço de um CLongBinary. A estrutura chama SQLGetData uma vez com um buffer pequeno, esperando que o driver para retornar o comprimento real dos dados. Se o driver retorna o comprimento real do objeto binário grande (BLOB), MFC realoca que a quantidade de espaço conforme necessário para buscar o BLOB. Se datasource retornará SQL_NO_TOTAL, indicando que não é possível determinar o tamanho do BLOB, MFC irá criar blocos menores. O tamanho inicial padrão é 64 K e blocos subseqüentes será o dobro do tamanho; por exemplo, a segunda será 128k, a terceira é de 256 K e assim por diante. O tamanho inicial é configurável.
Não vinculativos: Recuperando/enviando dados diretamente do ODBC com SQLGetData
Com este método você completamente ignorar as classes de banco de dados e lidar com a coluna de dados longos-se.
Vantagens:
Você pode armazenar em cache dados para disco se necessário, ou decidir dinamicamente a quantidade de dados para recuperar.
Desvantagens:
Você não receber suporte de AddNew ou Editar a estrutura, e você deve gravar código você mesmo execute funcionalidade básica (Excluir trabalho embora, uma vez que não é uma operação de nível de coluna).
Neste caso, a coluna de dados longos deve estar na lista de seleção do conjunto de registros, mas não deve ser ligada a pela estrutura. Uma maneira de fazer isso é fornecer sua própria instrução SQL via GetDefaultSQL ou como o argumento de lpszSQL para CRecordsetda função Abrir e não associar a coluna extra com uma chamada de função RFX _. ODBC requer que campos não acoplados aparecem à direita dos campos ligados, para adicionar suas colunas não acopladas ao final da lista de seleção.
&Nbsp aviso; Desde que a coluna de dados longos não é vinculada pela estrutura, as alterações a ele não ser tratadas com CRecordset:: Update chamadas. Você deve criar e enviar as exigido instruções SQL Inserir e Atualizar -se.
Técnico anotações por número |nbsp; &Notas técnicas por categoria