Dmitry -

Thanks for the reply. I've tried it with all blobs combined into one large VARCHAR(32000) field, but it still runs out of memory. Here's the custom table structure:

CP_MONO_MAIN_PATI_ (
ID INTEGER NOT NULL,
CPNUM INTEGER NOT NULL,
DFORM VARCHAR(1024),
DISHEET VARCHAR(32000),
DFORMLAST VARCHAR(24),
DESCRLAST VARCHAR(24),
CONTRALAST VARCHAR(24),
ADMINLAST VARCHAR(24),
MISSEDLAST VARCHAR(24),
INTERLAST VARCHAR(24),
SIDELAST VARCHAR(24),
MONITORLAST VARCHAR(24),
STORELAST VARCHAR(24)
);

The procedure that I gave as an example is actually using the above table, not the one first quoted. Apparently the engine isn't doing too well with large varchars in this type of scenario either.

Is there any way to free up resources on the fly so that the engine isn't caching too much memory?

Thanks.

David Keith

--- In firebird-support@yahoogroups.com, Dmitry Yemanov <dimitr@...> wrote:
>
> dkeith2 wrote:
>
> > Is there a setting in firebird.conf that would allow me to allocate more memory to the instance so that this query could run?
>
> No. This error means that the operating system simply doesn't have any
> available memory (or you get out of the process address space).
>
> > I've tried many permutations of this, but all eventually run out of resources.
>
> Don't use blobs instead of varchars unless strictly required. Your
> procedure creates a lot of temporary blobs (intermediate operation
> results). Every such blob occupies around <page size> bytes of memory
> for the whole transaction lifetime.
>
> FB 2.5 works better in this regard, but this practice is still not
> friendly to the engine.
>
>
> Dmitry
>