Цієї записці описується, як для отримання та надсилання ODBC SQL_LONGVARCHAR і SQL_LONGVARBINARY типів даних за допомогою класів MFC бази даних.
Огляд довгий Varchar/Varbinary підтримки
ODBC SQL_LONG_VARCHAR і SQL_LONGBINARY типів даних (згадується тут як довго стовпці даних) може провести величезну кількість даних. Є 3 способу може обробляти ці дані:
Стовпці довгий даних не підтримується для параметрів до запиту. Вони підтримуються лише для outputColumns.
Прив'язування довгий стовпець даних для CString/CByteArray
Переваги:
Такий підхід є простим для розуміння, і ви працюєте з знайомі класів. Рамках впроваджує CFormView до CString з DDX_Text. У вас багато загальних рядок або колекції функціональність з CString і CByteArray класи, і ви можете контролювати обсяг пам'яті, що виділяються на місцевому рівні провести значення даних. Рамках підтримує стару копію даних поля під час редагування або AddNew викликів функцій, і рамках може автоматично виявити зміни до даних для вас.
Приміткаnbsp; Оскільки CString призначений для роботи на символ даних і CByteArray для роботи над двійкові дані, рекомендуємо покласти характер даних (SQL_LO&NGVARCHAR) в CStringі двійкові дані (SQL_LONGVARBINARY) в CByteArray.
RFX функції для CString і CByteArray є додатковий аргумент, який дозволяє змінювати розмір за промовчанням пам'ять, виділених для проведення отримане значення для стовпця даних. Примітка у наступних заявах, функції, аргумент nMaxLength:
недійсним AFXAPI RFX_Text(CFieldExchange* pFX, const char *szName,
nbsp; CString & значення, int nMaxLength = 255, int nColumnType =
SQL_VARCHAR);
недійсним AFXAPI RFX_Binary(CFieldExchange* pFX, const char *szName, CByteArray& value,int nMaxLength = 255)
Якщо ви отримати довгий даних стовпця в CString або CByteArray, максимально повернувся, сума даних-за замовчуванням 255 байт. Нічого, крім цього ігнорується. У цьому випадку рамках буде кидати виняток AFX_SQL_ERROR_DATA_TRUNCATED. На щастя, ви можете збільшити явно nMaxLength на більше значення, аж до MAXINT.
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 на CLongBinary, член m_hData . Якщо це занадто малий, звільнення HGLOBAL і виділити один за розміром. Потім встановіть m_dwDataLength відображає новий розмір.
В іншому випадку, якщо m_dwDataLength перевищує розмір даних, що ви замінюєте, можна вільно і перерозподілити HGLOBALабо залишити його виділено. Не забудьте вказати кількість байтів, які дійсно використовуються в m_dwDataLength.
Як оновлення працює на CLongBinary
Це не є необхідним, щоб зрозуміти, як оновлення CLongBinary працює, але може бути корисним як приклад про те, як відправити довгий даних до джерела даних, якщо ви виберіть це третій метод, описаний нижче.
Приміткаnbsp; Для того, щоб бути включені в оновлення поля CLongBinary ви повинні чітко викликати SetFieldDirty поля. Якщо ви зробите будь-які зміни до поля, у тому числі, встановивши його значення &Null, ви повинні викликати SetFieldDirty.
Під час оновлення поля CLongBinary , класи бази даних за допомогою ODBC, DATA_AT_EXEC механізму (див. документацію ODBC на SQLSetPosrgbValue аргумент). Коли рамках готує вставити або оновлення заяву, замість того, вказуючи на HGLOBAL , що містить дані, Адреса CLongBinary встановлено як значення стовпця, замість цього, і індикатор довжини значення SQL_DATA_AT_EXEC. Пізніше коли оновлення заяву надсилається до джерела даних, SQLExecDirect повернеться SQL_NEED_DATA. Це попереджає рамках, що вартість парам для цього стовпця є насправді за адресою CLongBinary. Рамках закликає SQLGetData раз з невеликий буфер, очікуючи драйвера для повернення фактичного довжина даних. Якщо водій повертає фактичної довжини великих двійкових об'єктів (BLOB), MFC reallocates обсяг вільного місця, необхідну для вилучення BLOB-ОБ'ЄКТІ. Якщо джерело даних повертає SQL_NO_TOTAL, про те, що він не може визначити розмір BLOB-ОБ'ЄКТІВ, MFC буде створити більш дрібні блоки. Початковий розмір за промовчанням 64K, і подальші блоки буде подвоїти розмір; Наприклад, другий буде 128 К, по-третє, 256k і так далі. Початковий розмір налаштовується.
Не обов'язковим: Отримання/відправлення даних безпосередньо з ODBC з SQLGetData
За допомогою цього методу ви повністю обійти бази даних класи і справа з довгий даних стовпця себе.
Переваги:
Можна кешувати дані на диску, при необхідності, або вирішити динамічно, скільки даних для отримання.
Недоліки:
Ви не отримаєте в рамках Редагувати або AddNew підтримки, і ви повинні написати код себе для виконання основних функцій (Видалити працювати, оскільки це не стовпця рівня роботи).
У цьому випадку, довго даних стовпця потрібно вибрати список набір записів, але не повинні дотримуватися до рамках. Одним із способів для цього є постачання власний SQL-оператор через GetDefaultSQL або як аргумент lpszSQL CRecordset відкритий функціонувати і не пов'язують додаткові стовпці з на виклик функції RFX_. ODBC вимагає, що вільні поля відображаються праворуч від поля приєднані, тому додати вільне стовпців до кінця список вибору.
Попередження Оскільки ваш довгий даних стовпець не пов'язаний рамках, зміни до нього не здійснюватися з CRecordset::Update дзвінків. Ви повинні створити і відправити необхідні заяви SQL, Вставка та оновлення себе.
Технічні примітки за номером |nbsp; Технічні примітки за категоріями