Поделиться через

TN045: Поддержка MFC Или Database для длинных varchar или varbinary

  • Статья

 

ПримечаниеПримечание

Следующая техническая заметка не была обновлена со времени сначала была включена в подключенной документации.В результате некоторые процедуры и разделы могут оказаться устаревшей или неверны.Последние новости, рекомендуется поиск раздела процента в подключенном индексу документации.

Эта заметка описывается, как извлечь и отправить типы данных ODBC SQL_LONGVARCHAR и SQL_LONGVARBINARY, используя классы баз данных MFC.

Общие сведения о длинной поддержки varchar или varbinary

Типы данных ODBC SQL_LONG_VARCHAR и SQL_LONGBINARY (в сосланные здесь длинные столбцы данных) могут поддерживать огромные объемы данных.3 Способа можно обрабатывать эти данные.

  • Привязать его к CString/CByteArray.

  • Привязать его к CLongBinary.

  • Не привязывать его вообще не отправляются и восстановления, а не значение типа long данных вручную, независимо от классов базы данных.

Каждый из 3 методов имеет свои преимущества и недостатки.

Длинные столбцы данных не поддерживаются для параметра к запросу.Они поддерживаются только для outputColumns.

Привязка длинный столбец в CString/CByteArray

Преимущества:

Этот подход является простым понять и работе с знакомыми классами.Границы предоставляют поддержку CFormView для CString с DDX_Text.Имеется много общей функциональности строки или коллекции с классами CString и CByteArray, и можно отслеживать объем памяти, выделенной локально для хранения значения данных.Границы ведут старую копию данных поля во время Изменить или вызовы функций AddNew и границы могут автоматически обнаруживать изменения к данным.

ПримечаниеПримечание

Поскольку CString предназначен для работы с символьных данных и CByteArray для работы с двоичных данных, рекомендуется поместить символьные данные (SQL_LONGVARCHAR) в CString и двоичных данных (SQL_LONGVARBINARY) в CByteArray.

Функции RFX для CString и CByteArray имеют дополнительный аргумент, который позволяет переопределить используемый по умолчанию размер выделенной памяти для хранения извлеченное значение столбца данных.Обратите внимание, что аргумент nMaxLength в следующих объявлениях функций:

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);

При восстановлении длинный столбец данных в CString или CByteArray, то число, возвращаемое данных по умолчанию составляет 255 байт.За этим ничего не учитывается.В этом случае платформа будут вызывать исключение AFX_SQL_ERROR_DATA_TRUNCATED.К счастью, можно явным образом увеличить nMaxLength к большим значениям, до MAXINT.

ПримечаниеПримечание

Значение nMaxLength используется MFC, чтобы установить локальный буфер функции SQLBindColumn.Это локальный буфер для хранения данных и фактически не влияет на объем данных, возвращаемых драйвером ODBC.RFX_Text и RFX_Binary только один звонят с помощью SQLFetch для получения данных из конечной базы данных.Каждый драйвер ODBC имеет другое ограничение по количеству данных могут вернуть в одном выборки.Это ограничение может быть намного меньше, чем заданное значение в nMaxLength, в случае которого создается исключение AFX_SQL_ERROR_DATA_TRUNCATED.В следующих обстоятельствах, перейдите к использованию RFX_LongBinary вместо RFX_Text или RFX_Binary, так что все данные могут быть восстановлены.

ClassWizard привязывает SQL_LONGVARCHAR к CString или SQL_LONGVARBINARY к CByteArray.Если нужно выбрать более 255 байт, то, в которые выполняется восстановление в длинный столбец данных, можно указать точное значение nMaxLength.

При полном столбец данных, привязанный к CString или CByteArray при обновлении работы на местах просто так же, как и когда он привязан к SQL_VARCHAR или SQL_VARBINARY.Во время Изменить, значение данных кэшируется прочь и более поздние версии по сравнению при Обновить вызывается для обнаружения изменений к значению данных и задать пакостное и значения NULL для столбцов соответственно.

Привязка длинный столбец в CLongBinary

Если длинный столбец данных может содержать больше байтов MAXINT данных, необходимо учитывать, восстановив его в CLongBinary.

Преимущества:

Извлекает все это длинный столбец данных, доступной памяти.

Недостатки:

Данные хранятся в памяти.Этот подход также запретительно дорогий для очень больших объемов данных.Необходимо вызвать SetFieldDirty для связанных данных, чтобы убедиться, что поле доступно в операции Обновить.

При восстановлении длинные столбцы данных в CLongBinary, классы баз данных проверяют общий размер длинного столбца данных, а затем выберите пункт сегмент памяти HGLOBAL достаточно большой для хранения его все значения данных.Классы базы данных получают все значения данных в выбранное HGLOBAL.

Если источник данных не может возвратить ожидаемый размер длинного столбца данных, то границы будут вызывать исключение AFX_SQL_ERROR_SQL_NO_TOTAL.Если не удалось выделить HGLOBAL завершается ошибкой, возникает стандартное исключение памяти.

ClassWizard привязывает SQL_LONGVARCHAR или SQL_LONGVARBINARY к CLongBinary.Выберите CLongBinary как переменная типа в диалоговом окне добавления переменной-члена.ClassWizard затем добавьте вызов RFX_LongBinary к вызову DoFieldExchange и увеличивает общее количество связанных полей.

Обновление длинные значения столбца данных, сначала убедитесь, что установлен HGLOBAL достаточно большое, чтобы гарантировать, что новые данные путем вызова ::GlobalSize в элементе m_hDataCLongBinary.Если она слишком мал, выпуск и выберите одно HGLOBAL соответствующий размер.Затем установите m_dwDataLength, чтобы отразить новый размер.

В противном случае если m_dwDataLength превышает размер данных можно заменить, можно освободить и reallocate HGLOBAL или оставьте он выделяется.Убедитесь, чтобы отобразить число байтов, фактически используемых в m_dwDataLength.

Как работает обновление CLongBinary

Не требуется понимать, как работает обновление CLongBinary, но может быть полезным, например о том, как отправлять длинные значения данных к источнику данных при выборе этого третий метод, описанных ниже.

ПримечаниеПримечание

В поле CLongBinary, включаемые в обновлении необходимо явно вызывать SetFieldDirty для поля.При внесении любых изменений к полю, включая устанавливать его пустым, необходимо вызвать метод SetFieldDirty.Кроме того, необходимо вызвать SetFieldNull, если второй параметр Ложь, чтобы пометить поля как имеющий значение.

При обновлении поля CLongBinary механизм DATA_AT_EXEC ODBC использования классов базы данных (в документации по ODBC в аргументе rgbValue SQLSetPos).Когда границы откладывается insert или update, оператор вместо этого они указывали на HGLOBAL, содержащий данные, адресCLongBinary набор в качестве значения столбцов, а набор индикаторов длины в SQL_DATA_AT_EXEC.Позже, при выписка обновления будет отправлена к источнику данных, SQLExecDirect возвращает SQL_NEED_DATA.Это платформа, что значение alerts, param для этого столбца виртуальный адрес CLongBinary.Платформа вызывает функцию SQLGetData раз при небольшой буфер, ожидая, что драйвер возвращает фактическую длину данных.Если драйвер возвращает фактическую длину большого двоичного объекта (blob), то MFC reallocates столько места, сколько необходимо для выборки большой двоичный объект.Если источник данных возвращает SQL_NO_TOTAL, что указывает на то, что он не может определить размер большого двоичного объекта MFC создает более мелких фрагментов.По умолчанию исходный размер 64K и последующие блоки размером будут в двукратном; например, будет 128K второй, третий 256K и т дИсходный размер можно настраивать.

Не привязке. Восстановление/отправляющего данные непосредственно из ODBC с помощью функции SQLGetData

С помощью этого метода можно самостоятельно полностью обходите классы баз данных и дело с длинным столбцом данных.

Преимущества:

Можно кэшировать данные на диск, если это необходимо или динамически решите, какой объем данных, который необходимо извлечь.

Недостатки:

Вы не получаете поддержку Изменить или AddNew границ и самостоятельно написать код для выполнения основных функций (Удалить работает однако поскольку нет операции на уровне столбца).

В этом случае длинный столбец данных, должен находиться в списке выбора набора записей, но не должен быть привязан к рамкам.Одним из способов сделать это предоставить собственное инструкцию SQL с помощью GetDefaultSQL или в качестве аргумента функции Открыть entity_CODECRecordset lpszSQL и не привязывать дополнительный столбец с вызовом функции RFX_.ODBC требует несвязанные поля отображаются справа от связанных полей, поэтому добавляет свои несвязанный столбец или столбцы в конец списка выбора.

ПримечаниеПримечание

Поскольку системному длинный столбец данных не привязан к ним платформой, изменения не будут обрабатываться с вызовами CRecordset::Update.Необходимо самостоятельно создавать и отправлять необходимое SQL INSERT и выписки UPDATE.

См. также

Другие ресурсы

Технические замечания по номеру

Технические замечания по категориям