TN045: Supporto di MFC Per Database a Varchar/Varbinary lungo
[!NOTA]
La seguente nota tecnica non è stata aggiornata dalla prima volta che viene inclusa nella documentazione online.Di conseguenza, alcune procedure e argomenti potrebbero non essere aggiornati o errati.Per le informazioni più recenti, è consigliabile cercare l'argomento di interesseindice della documentazione online.
Questa nota viene descritto come recuperare e inviare i tipi di dati ODBC SQL_LONGVARCHAR e di SQL_LONGVARBINARY utilizzando le classi di database MFC.
Cenni preliminari sul supporto esteso di Varchar/Varbinary
I tipi di dati ODBC SQL_LONG_VARCHAR e di SQL_LONGBINARY (indicati qui come colonne di dati long) possono utilizzare più grande quantità di dati.Vi sono 3 modalità che è possibile gestire questi dati:
Associazione a CString/CByteArray.
Associazione a CLongBinary.
Non è associata alcuna proprietà e non recupera e non invia il valore dei dati long manualmente, indipendente dalle classi di database.
Ciascuno dei tre metodi presenta vantaggi e svantaggi.
Le colonne di dati lunghe non sono supportate per i parametri a una query.Sono supportate solo per i outputColumns.
Associazione di una colonna di dati lunga a un CString/CByteArray
Vantaggi:
Questo approccio è semplice comprensione e di lavoro con le classi comuni.Il framework fornisce il supporto di CFormView a CString con DDX_Text.Sono disponibili molti di funzionalità generale della raccolta o della stringa con le classi di CByteArray e di CString ed è possibile modificare la quantità di memoria allocata in locale per contenere il valore dei dati.Il framework gestisce una copia precedente dei dati del campo durante Modifica o chiamate di funzione di AddNew e il framework può rilevare automaticamente le modifiche ai dati.
[!NOTA]
Poiché CString è progettato per essere utilizzato sui dati di tipo carattere e CByteArray per eseguire sui dati binari, è consigliabile viene inserito i dati di tipo carattere (SQL_LONGVARCHAR) in CStringe i dati binari (SQL_LONGVARBINARY) in CByteArray.
Le funzioni RFX per CString e CByteArray dispongono di un argomento supplementare che consente di eseguire l'override della dimensione predefinita della memoria allocata per utilizzare il valore recuperato per la colonna di dati.Annotare l'argomento del nMaxLength nelle seguenti dichiarazioni di funzione:
void AFXAPI RFX_Text(CFieldExchange* pFX, const char *szName,
CString& value, int nMaxLength = 255, int nColumnType =
SQL_VARCHAR);
void AFXAPI RFX_Binary(CFieldExchange* pFX, const char *szName,
CByteArray& value,int nMaxLength = 255);
Se si recupera una colonna di dati lunga in CString o in CByteArray, la quantità restituita di dati è, per impostazione predefinita, a 255 byte.Nient'altro che questo viene ignorato.In questo caso, il framework genera l'eccezione AFX_SQL_ERROR_DATA_TRUNCATED.Fortunatamente, è possibile creare in modo esplicito aumentare il nMaxLength a ulteriori valori, fino a MAXINT.
[!NOTA]
Il valore di nMaxLength viene utilizzato da MFC per impostare il buffer locale della funzione di SQLBindColumn .Si tratta del buffer locale per l'archiviazione dei dati e non influisce sulla quantità di dati restituiti dal driver ODBC.RFX_Text e RFX_Binary hanno solo una chiamata tramite SQLFetch per recuperare i dati dal database back-end.Ogni driver ODBC presenta un limite diverso della quantità di dati che possono restituire in un'unica raccolta.Questo limite può essere molto più piccolo set di valori in nMaxLength in questo caso, l'eccezione AFX_SQL_ERROR_DATA_TRUNCATED verrà generata un'eccezione.In queste condizioni, l'opzione a l RFX_LongBinary anziché RFX_Text o di RFX_Binary in modo da poter recuperare tutti i dati.
ClassWizard verrà associata SQL_LONGVARCHAR a CString, o SQL_LONGVARBINARY a CByteArray automaticamente.Se si desidera allocare più di 255 byte in cui recuperare la colonna di dati lunga, è quindi possibile fornire un valore esplicito per nMaxLength.
Quando una colonna di dati lunga viene associata a CString o a CByteArray, aggiornando funzionamento di campo solo lo stesso di quando è associata a uno SQL_VARCHAR o a SQL_VARBINARY.Durante il Modifica, il valore dei dati viene memorizzata nella cache tramite e successivamente viene confrontato quando Aggiorna viene chiamato per rilevare le modifiche al valore di dati e per impostare il modificato e i valori null per la colonna in modo appropriato.
Associazione di una colonna di dati lunga a un CLongBinary
Se la colonna di dati lunga può contenere più byte di MAXINT dei dati, è consigliabile considerare la possibilità di recuperarle in CLongBinary.
Vantaggi:
Ciò recupera l'intera colonna di dati lunga, fino alla memoria disponibile.
Svantaggi:
I dati vengono utilizzati in memoria.Questo approccio è anche proibitivamente dispendioso per quantità di dati molto grandi.È necessario chiamare SetFieldDirty per il membro dati associato per proteggere il campo sono inclusi in un'operazione di Aggiorna .
Se si recupera le colonne di dati estesi in CLongBinary, le classi di database nella dimensione totale della colonna di dati lunga, quindi allocare un segmento di memoria di HGLOBAL sufficientemente grande per utilizzarla il valore completo dei dati.Le classi di database verrà quindi recuperare il valore completo dei dati in HGLOBALallocato.
Se l'origine dati non può restituire la dimensione prevista della colonna di dati lunga, il framework genera l'eccezione AFX_SQL_ERROR_SQL_NO_TOTAL.Se allocare HGLOBAL non riesce, viene generata un'eccezione standard di memoria viene generata un'eccezione.
ClassWizard verrà associata SQL_LONGVARCHAR o SQL_LONGVARBINARY a CLongBinary automaticamente.CLongBinary selezionato come la variabile nella finestra di dialogo variabile membro.ClassWizard aggiunge quindi una chiamata di RFX_LongBinary alla chiamata di DoFieldExchange e incrementerà il numero totale di campi associati.
Per aggiornare i valori lunghi della colonna di dati, assicurarsi innanzitutto che HGLOBAL allocato sia sufficiente utilizzare i nuovi dati chiamando ::GlobalSize al membro di m_hData di CLongBinary.Se è troppo piccolo, rilasciare HGLOBAL e allocare uno le dimensioni corrette.m_dwDataLength impostare per riflettere la nuova dimensione.
In caso contrario, se m_dwDataLength è maggiore delle dimensioni dei dati che si sta sostituendo, è possibile disponibile e ridistribuire HGLOBAL, o lasciarlo allocato.Assicurarsi indicare il numero di byte effettivamente utilizzati in m_dwDataLength.
Come aggiornando un CLongBinary Works
Non è necessario capire come aggiornare il funzionamento di CLongBinary , ma può essere utili come esempio su come inviare i valori dei dati long a un'origine dati, se si sceglie il terzo metodo, descritta di seguito.
[!NOTA]
Affinché un campo di CLongBinary da includere in un aggiornamento, è necessario chiamare in modo esplicito SetFieldDirty per il campo.Se si apporta una modifica a un campo, inclusi su null, è necessario chiamare SetFieldDirty.È inoltre necessario chiamare SetFieldNull, con il secondo parametro che è FALSE, per contrassegnare il campo come dotata di un valore.
Quando si aggiorna un campo di CLongBinary , il meccanismo di DATA_AT_EXEC di utilizzo ODBC delle classi di database (vedere la documentazione ODBC nell'argomento del rgbValue di SQLSetPos).Quando il framework di inserimento o istruzioni di aggiornamento, anziché puntare a HGLOBAL contenente i dati, l'indirizzo di CLongBinary sono impostati come valore della colonna anziché e l'indicatore di lunghezza impostato su SQL_DATA_AT_EXEC.In un secondo momento, quando l'istruzione update viene inviata all'origine dati, SQLExecDirect restituirà SQL_NEED_DATA.In questo modo si segnala il framework che il valore di param per questa colonna viene effettivamente l'indirizzo di CLongBinary.Il framework chiama una volta SQLGetData con un piccolo buffer, prevedente il driver per restituire effettiva lunghezza dei dati.Se il driver restituisce effettiva lunghezza dell'oggetto binario di grandi dimensioni (il BLOB), MFC ridistribuisce in base alle esigenze più spazio per recuperare il BLOB.Se l'origine dati restituisce SQL_NO_TOTAL, per indicare che non può determinare la dimensione del BLOB, MFC creerà più piccoli blocchi.La dimensione iniziale predefinita è previsto e i blocchi successivi verranno doppio la dimensione, ad esempio, il secondo verrà 128K, il terzo è 256K, e così via.La dimensione iniziale è configurabile.
Non associata: Recuperare/che invia i dati direttamente dall'ODBC con SQLGetData
Con questo metodo si ignora completamente le classi di database e l'affare con la colonna di dati lunga manualmente.
Vantaggi:
È possibile memorizzare i dati su disco se necessario, o decidere dinamicamente quantità di dati da recuperare.
Svantaggi:
Non si ottiene il supporto di Modifica o di AddNew del framework ed è necessario scrivere il codice è stato scritto per eseguire la funzionalità di base (Elimina viene eseguito in ogni caso, poiché non è un'operazione a livello di colonna).
In questo caso, la colonna di dati lunga deve essere nell'elenco di selezione del recordset, ma non deve essere associata dal framework.A tale scopo è quello di fornire l'istruzione SQL personalizzata tramite GetDefaultSQL o come argomento lpszSQL alla funzione di Apri di entity_CODECRecordset e non di associare la colonna aggiuntiva a una chiamata di funzione di RFX_.ODBC è necessario che i campi non associati vengano visualizzate a destra di campi associati, in modo da aggiungere la colonna o colonne non associate all'elenco selezionare.
[!NOTA]
Poiché la colonna di dati lunga non è associata dal framework, le modifiche a non verranno gestite dalle chiamate di CRecordset::Update .È necessario creare e inviare SQL obbligatorio INSERISCI e istruzioni di AGGIORNA manualmente.