On Tue, 13 Jul 2004 09:37:28 +0200,
Johannes Pretorius <johannes@...> wrote:

JP> //================== SNIP =============================
JP> This setting specifies (to gpre) the maximum number of bytes that an application
JP> is expected to write to any segment in the column. The default segment length is 80.
JP>
JP> ---> Normally, an application should not attempt to write segments larger than the segment
JP> length defined in the table; doing so overflows the internal segment buffer, corrupting
JP> memory in the process.
JP>
JP> The segment length setting does not affect InterBase system performance. Choose the
JP> segment length most convenient for the specific application. The largest possible segment
JP> length is 32 kilobytes (32,767 bytes).
JP> //================== END SNIP ===================
JP>
JP> Now I have tried to search IBPhoenix about this and the Firebird mailing list, but I guess my
JP> searching capabilities is not up to scratch as I wanted to see if this has been a issue for
JP> users in the past and if this has been resolved in 1.5 of Firebird ??

GRPE programs use the declared segment size to allocate buffers that
will get used while copying in/out the blob. It might effectively be
possible in such an application to overflow these GPRE-produced buffers
by tweaking and requesting transfers larger than those.

In a DSQL application though, this declared segment size is not used.
That value can be anything or can be unspecified. The programmer is sole
responsible for allocating his/her own buffers (if applicable) and
reading or writing by any segment size he/she likes, to the maximum
segment size of 32767 bytes. You can perfectly write sequentially in a
single blob 8 Kb, then 4 Kb, then 12 Kb, then 353 bytes. So the segments
are absolutely not of a fixed size for a whole blob. They can vary. The
declared segment size is then only there for declarative purposes and
some tools or interfaces might use it as a hint or anyway they'd like.

At least this how I understood these matters from my API user's point of
view (I'm not touching the core engine code).

--
Olivier Mascia