If you follow Geoff's advice and try separating away the data aware stuff to
take finer control over the insert you can use a TIB_DSQL which leaves the
buffer at its preallocated size as it is reused. It remains allocated until
the statement is unprepared.

So, what you could do is pre-initialize the input parameter for the BLOB to
the average size plus a little and leave it.

By using a dataset you are going to eat memory like crazy because for each
insert you are going to be buffering each blob in a separate record buffer.
If you want to continue browsing among the images I suppose this is ideal
but in most cases I think once in people want to move on and will not
actually be interested in browsing until a later time.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Nello Sestini" <nello@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, April 04, 2001 6:16 AM
Subject: Re: [IBO] Large Blob Insertion


> Brian/Geoff
>
> > The Windows API RichEdit control supports streaming via a callback
> > mechanism. Since both the VCL and the IP RichEdit controls use this
> > WinAPI richedit, they also use this callback mechanism for streaming.
> > So when UpdateData is called above, it sends a message to the control
> > which then issues a series of callbacks to a defined function (see
> > StreamSave in the comctrls.pas VCL unit).
>
> The VCL wrapper sends an EM_STREAMOUT message to the underlying windows
> control passing it a pointer to the callback function StreamSave
>
> > The problem is that the size of the final data is not known until
> > after it has been converted. So the API control simply converts a
> > small amount at a time and sends that small amount with each
> > callback - apparently 4095 bytes.
> >
> > I cannot find anyway of telling the control to change its buffer size.
> > (That does not mean it doesnt exist, only that I cant find it.)
> >
>
> I can't find anything either. Not even a place where MS documents
> the 4095 or whatever it is.
>
> But this isn't really so bad.
>
> The problem isn't that these chunks are small - the problem is that
> the small chunk size gets used as the reallocate delta by the stream.
>
> And I think the VCL does provide a convenient hook for getting in between
> the windows control interface and the stream. Via a TConversion.
>
> The callback function passes the data it gets from the control
> to the stream like this:
>
> if StreamInfo^.Converter <> nil then
> pcb := StreamInfo^.Converter.ConvertWriteStream(StreamInfo^.Stream,
> PChar(pbBuff), cb);
>
> and you CAN provide your own converter object - it's set via the
> DefaultConverter property. A TConverter is just a pair of functions
> to convert from stream to buffer and from buffer to stream.
>
> In this custom converter you could allocate a LARGER buffer and
> "buffer the buffers" passing larger chunks on to the stream.
>
> > IMO the ideal solution would have been for the VCL to assemble the
> > result itself (since it is rather a special situation) and then pass
> > of the total result on the destination stream. But they do not do
> > that - I guess it does not matter if it was just being streamed to
> > file.
>
> I suppose that's what this amounts to.
>
> -ns
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>