Firebird и блобы больше 2GB
Привет всем.
В дистрибутив NetProvider-а были добавлены примеры (проекты на C# для VS2008, VS2010, VS2012), в числе которых — запись и чтение бинарного блоба размером 8GB (каталог Sample_0007__8GB_bin_blob).
Firebird (2.5) без проблем сохраняет и позволяет прочитать такие блобы. Но ни через API, ни через OCTET_LENGTH не в состоянии вернуть правильный размер такого блоба.
ISC API
Через API размер блоба определяется с помощью функции isc_blob_info и тега isc_info_blob_total_length (id: 6).
Для блоба, размером 8GB, серверный клиент возвращает длину в виде 4-байтного числа [буфер с ответом: (tag)06 04 00 00 00 00 00 | (end_tag)01 cc cc cc cc].
Хотя, для 3GB блоба, почему-то, возвращается уже 8-байтное число [буфер с ответом: (tag)06 08 00 00 00 00 c0 00 00 00 00 | (end_tag)01 cc cc cc]. Что несколько озадачивает…
OCTET_LENGTH
С этой SQL функцией все просто — она возвращает INTEGER (INT32), поэтому даже теоретически не в состоянии вернуть значения больше 2GB. Для 3GB блоба эта функция возвращает -1073741824.
FB3 (сборка 30319) OCTET_LENGTH все еще продолжает возвращать INTEGER. Наверное, руки пока не дошли перевести на BIGINT, который в FB3 стал допустимым для первого диалекта.
Так что, в плане определения размера блоба у Firebird пока все грустно непонятно.
И возня с этой непонятностью сожрала у меня первую половину текущего дня.
dimitr on 29 мая, 2013
внутренняя длина блоба — ULONG blb_length. При 8 гигах она тупо заворачивается, при 3 еще влезает, но возвращается уже как INT64 (ибо результат isc_info_blob_total_length — знаковый и в SLONG оно не лезет). Я вообще удивлен что такой блоб создался. Думаю, что только кроме как читать/писать через АПИ с ним ничего сделать не получится, т.к. строково-блобовые функции, например, в большинстве своем завязаны на blb_length и будут жутко глючить.