Справочник по API

| | |

Разъяснение о структуре записи журнала

|

Это исправление документации относится к Примечанию 3 для Таблицы 103. Структура записи журнала для добавления/удаления/не-изменения длинного поля в разделе |Записи журнала о работе с длинными полями |в теме под заголовком Записи журнала DB2 UDB. |Текст Примечания 3 следует читать так:

|

3. Длина данных длинного поля в секторах по 512 байт (действительная длина данных указывается |в первых 4 байтах дескриптора LF, который записывается в последующей записи журнала о вставке/удалении/изменении |как часть форматированной записи пользовательских данных). |Длина этого поля всегда положительна. |Менеджер длинных полей никогда не записывает в журнал записи |о вставке, удалении или изменении данных длинных полей с нулевой длиной.

| | |

Параметр oBackupsize функции API db2Backup

|

В DB2 Версии 8 параметр oBackupsize для API db2Backup относится к полным |резервным копиям, а не к разностным или инкрементным резервным копиям. Параметр oBackupsize - размер образа резервной копии (Мбайт).

Поддержка опции SYNCPOINT

В Версии 8 игнорируется опция SYNCPOINT для API sqlesetc, sqleqryc и sqlaprep; она доступна только для обратной совместимости.

Новое поле для структуры SQLEDBDESC

В API sqlecrea добавлено новое поле для поддержки прямого ввода/вывода.

Имя поля
Unsigned char sqlfscaching
Описание
Кэширование файловой системы
Значения
0
Кэширование файловой системы включено для текущего табличного пространства
1
Кэширование файловой системы отключено для текущего табличного пространства
другой код
Кэширование файловой системы включено для текущего табличного пространства

Поправка о новом поле в структуре SQLB-TBSPQRY-DATA

В структуру SQLB-TBSPQRY-DATA было добавлено новое поле unsigned char fsCaching. Это новое поле поддерживает прямой ввод-вывод. Хотя в документации указан 32-битный размер, правильный размер - 31-битный.

[ Начало страницы |Страница назад | Страница вперед | Содержание ]