Questa nota viene descritto come recuperare e inviare i tipi di dati ODBC SQL_LONGVARCHAR e SQL_LONGVARBINARY che utilizza le classi di database MFC.
Panoramica delle lunghe Varchar/Varbinary sostenere
I tipi di dati ODBC, SQL_LONG_VARCHAR e SQL_LONGBINARY (cui qui come lunghe colonne di dati) possono contenere enormi quantità di dati. Ci sono 3 modi è possibile gestire questi dati:
Colonne di dati Long non sono supportate per parametri per una query. Essi sono supportati solo per outputColumns.
Associazione una lunga colonna di dati a un CString/CByteArray
Vantaggi:
Questo approccio è semplice da capire, e si lavora con le classi familiare. Il framework fornisce supporto CFormView per CString con DDX_Text. Hai un sacco di stringa generale o funzionalità di raccolta con le classi di CByteArray e CString , ed è possibile controllare la quantità di memoria allocata localmente per contenere il valore di dati. Il framework gestisce una vecchia copia del campo dati durante la Modifica o chiamate di funzione AddNew e il quadro può rilevare automaticamente le modifiche ai dati per voi.
&Notanbsp; Poiché CString è progettato per lavorare su dati di tipo carattere e CByteArray per lavorare su dati binari, è consigliabile inserire i dati di tipo carattere (SQL_LONGVARCHAR) in CStringe i dati binari (SQL_LONGVARBINARY) in CByteArray.
Le funzioni RFX per CString e CByteArray hanno un argomento aggiuntivo che consente di ignorare le dimensioni predefinite di memoria allocata per contenere il valore recuperato per la colonna di dati. Nota l'argomento nMaxLength nelle seguenti dichiarazioni di funzione:
public static void AFXAPI RFX_Text(CFieldExchange* pFX, const char *szName,
nbsp; CString & value, int nMaxLength = 255, int nColumnType =
SQL_VARCHAR);
public static void AFXAPI RFX_Binary(CFieldExchange* pFX, const char *szName, CByteArray& value,int nMaxLength = 255)
Se si recupera una colonna di dati di tipo long in un CString o CByteArray, ha restituito la massima quantità di dati è, per impostazione predefinita, 255 byte. Nulla di là di questo viene ignorato. In questo caso, il quadro verrà generata l'eccezione AFX_SQL_ERROR_DATA_TRUNCATED. Fortunatamente, è possibile aumentare in modo esplicito nMaxLength a valori maggiori, fino a MAXINT.
ClassWizard verrà associato un SQL_LONGVARCHAR un CString, o un SQL_LONGVARBINARY per un CByteArray per te. Se si desidera assegnare più di 255 byte in cui recuperare la colonna di dati di tipo long, è quindi possibile fornire un valore esplicito per nMaxLength.
Quando una colonna di dati long è associata a un CString o CByteArray, l'aggiornamento del campo funziona proprio come quando si è associato a una sp_trace_generateeventVARCHAR o sp_trace_generateeventVARBINARY. Durante la Modifica, il valore dei dati è memorizzata nella cache lontano e più tardi rispetto Update viene chiamato per rilevare le modifiche apportate al valore dei dati e impostare i valori di sporco e Null per la colonna in modo appropriato.
Associazione una lunga colonna di dati a un CLongBinary
Se la colonna di dati long può contenere più MAXINT byte di dati, probabilmente dovreste considerare recuperandolo in un CLongBinary.
Vantaggi:
Questo recupera una colonna di dati intero long - fino a memoria disponibile.
Svantaggi:
I dati si tiene in memoria. Questo approccio è anche proibitivo per grandi quantità di dati. È necessario chiamare SetFieldDirty per il membro dati associati garantire che il campo è incluso in un'operazione di aggiornamento.
Se si recuperano colonne di dati di tipo long in un CLongBinary, le classi di database controlla la dimensione totale della colonna dati long, quindi allocare un segmento di memoria HGLOBAL abbastanza grande per tenere il valore intero di dati. Le classi di database quindi recuperano il valore intero dati allocati HGLOBAL.
Se l'origine dati non può restituire le dimensioni previste della colonna dati long, il framework genererà l'eccezione AFX_SQL_ERROR_SQL_NO_TOTAL. Se il tentativo di allocare il HGLOBAL non riesce, viene generata un'eccezione di memoria standard.
ClassWizard verrà associato un SQL_LONGVARCHAR o SQL_LONGVARBINARY un CLongBinary per te. Selezionare CLongBinary come il tipo di variabile nella finestra di dialogo Aggiungi variabile membro. ClassWizard poi aggiungere una chiamata a RFX_LongBinary alla vostra chiamata DoFieldExchange e incrementare il numero totale di campi associati.
Per aggiornare lungo i valori di colonna dati, prima assicurarsi che l' allocati HGLOBAL è abbastanza grande per tenere i nuovi dati chiamando :: GlobalSize nel membro m_hData del CLongBinary. Se è troppo piccolo, rilasciare il HGLOBAL e allocare una dimensione appropriata. Impostare quindi m_dwDataLength in modo da riflettere le nuove dimensioni.
In caso contrario, se m_dwDataLength è maggiore della dimensione dei dati che si stanno sostituendo, libero e riallocare il HGLOBALo lasciarlo allocato. Assicurarsi di indicare il numero di byte effettivamente utilizzato in m_dwDataLength.
Aggiornamento come funziona un CLongBinary
Non è necessario capire come l'aggiornamento di un CLongBinary funziona, ma può essere utile, ad esempio su come inviare i valori di dati long a un'origine dati, se si sceglie questo terzo metodo, descritto di seguito.
&Notanbsp; Al fine di un campo CLongBinary da includere in un aggiornamento, è necessario chiamare in modo esplicito SetFieldDirty per il campo. Se si effettua qualsiasi modifica a un campo, inclusa l'impostazione è Null, è necessario chiamare SetFieldDirty.
Quando si aggiorna un campo CLongBinary , le classi di database utilizzano il meccanismo di DATA_AT_EXEC di ODBC (vedi documentazione ODBC SQLSetPosdi rgbValue argomento). Quando il quadro si prepara l'inserto o istruzione update, anziché puntare al HGLOBAL che contiene i dati, l' indirizzo della CLongBinary è impostato come valore della colonna, invece, e l'indicatore di lunghezza impostata su SQL_DATA_AT_EXEC. Più tardi, quando l'istruzione update viene inviato all'origine dati, SQLExecDirect restituisce SQL_NEED_DATA. Questo quadro un avviso che il valore di param per questa colonna è in realtà l'indirizzo di un CLongBinary. Il framework chiama SQLGetData una volta con un piccolo buffer, prevedendo il driver per restituire la lunghezza effettiva dei dati. Se il driver restituisce la lunghezza effettiva dell'oggetto binario di grandi dimensioni (BLOB), MFC rialloca tanto spazio quanto necessario per recuperare il BLOB. Se la proprietà datasource restituisce SQL_NO_TOTAL, che indica che essa non può determinare la dimensione del BLOB, MFC creerà blocchi di dimensioni inferiori. La dimensione iniziale predefinita è 64K e blocchi successivi sarà il doppio delle dimensioni; ad esempio, il secondo sarà 128K, il terzo è 256 K e così via. La dimensione iniziale è configurabile.
Non vincolante: Recupero/invio dati direttamente da ODBC con SQLGetData
Con questo metodo si completamente ignorare le classi di database e trattare con la colonna di dati long te stesso.
Vantaggi:
È possibile memorizzare nella cache i dati su disco se necessario, o decidere in modo dinamico la quantità di dati da recuperare.
Svantaggi:
Non ottenete Edit del framework o supporto AddNew , e si deve scrivere codice te stesso per eseguire le funzionalità di base (Delete funziona però, dal momento che non è un'operazione di livello colonna).
In questo caso, la colonna di dati long deve essere nell'elenco di selezione dell'oggetto recordset, ma non deve essere associata a dal framework. Un modo per farlo è quello di fornire il proprio istruzione SQL via GetDefaultSQL o come l'argomento lpszSQL CRecordsetdella funzione aperta e non legano la colonna supplementare con una chiamata della funzione RFX_. ODBC richiede che i campi non associati riportati a destra di campi associati, quindi aggiungere le colonne non associato alla fine dell'elenco di selezione.
Avvertenzanbsp; Poiché la colonna di dati a lungo non è vincolata il quadro, le modifiche ad esso non verranno gestite con chiamate possibile . È necessario creare e inviare le necessarie istruzioni SQL I&NSERT e UPDATE te stesso.
&Note tecniche per numero |nbsp; Note tecniche per la categoria