At 08:04 PM 11/01/2005 -0500, you wrote:

>:: A varchar will be stored on disk with the trailing blanks
>:: compressed to two bytes. A memo field will use eight bytes
>:: plus 17 bytes (blob header & page index) plus the length of
>:: the data on page, plus data.
>
>Thanks. I was under the assumption that they were stored as full length as
>some dbs too. Im glad its not.

Ann H wrote:
A varchar will use its
:: declared length plus two bytes in a network transfer (I
:: think - there's been talk about changing that and I don't
:: know the current status), but a blob is a whole separate call.

InterBase, up to and including IB 6, stores varchars compressed but expands
them to full declared size +2 for transport across the wire. I seem to
recall that Fb 1.0 does that too, not certain without looking it up. But
Fb 1.5 sends the varchar as its actual (stored) length + 2 bytes. Could it
be that it hasn't been fixed in Vulcan yet? <g>

>When you say talk of changingg this - to what? Storing the full length? If
>we are changing things - Id like to see a memo option that causese it to be
>retrieved inline. I often use memos for smaller data that in some rows might
>get big, but is usually quite small. Would be a perfect "tuning" optin on
>the field options.

If by "retrieved inline" you mean "retrieved on demand" then that's already
the default behaviour. You can test this yourself by using isql to query a
table that houses a blob . By default, you get only the blob_id
(BLOBDISPLAY is off). You can do SET BLOBDISPLAY ALL to retrieve the blob
contents of any blob; or SET BLOBDISPLAY <sub_type> to retrieve only those
of a particular subtype..

As I understand, you're using the .NET provider. Ask Carlos what the
property is to control blob traffic across that interface. You might be
pleasantly surprised.

That's not an argument for storing URLs as blob, btw....

./hb