I'm gonna throw out (below) a few known instances of this error
retrieved from a quick web search. Looks to me like the second blob
issue may have some pertinence.

Regards,
Andrew Ferguson.

-----

Error: SQLDA missing or incorrect number/type of variables. - by
Borland Developer Support Staff

Abstract:This article describes a work around to this error when
using Interbase and stored procedures.

QUESTION:
How can I work past this error?

ANSWER:
The solution was to prepare and unprepare the storedproc with every
iteration. This is a little inefficient, but not that bad because
once the procedure is executed, it's cached on the server anyway.

-----

> DK> Dynamic SQL Error
> DK> -SQL error code = -804
> DK> -SQLDA missing or incorrect version, or incorrect number/type

of variables

>
> This error seems to be a very old one.
> Today I receive it even in IB 6.0.1.

Ok, let's reformulate my post. I know that selecting non-existent
blob is
not a good idea. I know that new constructed blob must be stored in
record,
not sent to client. But, error message seems to be a bit confusing.

Also, I see it only in ISQL, but all another tools give same error
message
that was reported in bug with GRANT FIELD1, FIELD2 ... executed after
GRANT FIELD1.

--- In ib-support@y..., Helen Borrie <helebor@t...> wrote:
> At 04:55 PM 07-05-02 +0200, you wrote:
> >Hi!
> >
> >The following problems happen on my FB's systems. (3 independent
system,
> >with different Opsystem, but the problems are same)
> >Unfortunately the probles are not permanent. Only sometimes.
~1/day. But
> >this systems are 7*24 safety systems, and this is unacceptable.
> >
> >Long ago wa use FB RC2 with Borland DBExpress, with no problem.
> >Now, we upgrade the systems to Lastest FB, and the Lastest
DBExpress,
> >and change the DB structure.
> >
> >I dont use storedprocs, triggers, UDF's. Only simple SELECT,
UPDATE and
> >DELETE.
> >
> >1.
> >SQL: SELECT SZEMELYAZ, DATUM, HETNAP, NAPTIPUS, MUNKAREND,
> >EREDETIMUNKAREND, MRMUSZAK, MUSZAKCSOPORT, MUSZAKJELZO,
ADATJAVITOTT,
> >KEZINAPLO, KEZIELOJEGYZES, HIBASNAP, ELLENORZOTT,
EGESZNAPOSTAVOLLET_JC,
> >BE_FORRAS, BE_IDO, BE_IRANY, BE_ESEMENY, BE_SPEC, KI_FORRAS,
KI_IDO,
> >KI_IRANY, KI_ESEMENY, KI_SPEC, BE_ELMELETI, KI_ELMELETI, BE_MUNKA,
> >KI_MUNKA, E_KEZI_JC, E_KEZI_KEZDET, E_KEZI_VEGE, E_KEZI_FIX_JC,
> >E_KEZI_FIX_KEZDET, E_KEZI_FIX_VEGE, E_TERMINAL_JC,
UTOLSOFELDOLGOZAS,
> >MRMCSERE_IDO, MRMCSERE_KEZELOAZ, MRMCSERE_PCAZ, MRMCSERE_TIPUS,
> >MRMCSERE_MRAZ, MRMCSERE_SPEC, BIN_DATA, BIN_WORK FROM MI_NAPIADAT
WHERE
> >SZEMELYAZ=:P_SZEMELYAZ AND DATUM=:P_DATUM
> >Table (MI_NAPIADAT): some integer, and float field and
> > "BIN_DATA" VARCHAR(4000) CHARACTER SET WIN1250,
> > "BIN_WORK" VARCHAR(4000) CHARACTER SET WIN1250,
> >
> >This SQL with this table, sometimes generate the following result:
> >"Cursor unknown" and the interbase.log: "gds_alloc: memory pool
> >corrupted"
> >
> >And then minute-to-minute is much "gds_free: attempt to release bad
> >block" and finally: "C:\WinAccess\IB\bin\ibserver.exe: terminated
> >abnormally (-1)"
> >And ... Restart...
> >
> >2.
> >SQL: SELECT SZEMELYAZ, DATUM, HETNAP, NAPTIPUS, MUNKAREND,
> >EREDETIMUNKAREND, MRMUSZAK, MUSZAKCSOPORT, MUSZAKJELZO,
ADATJAVITOTT,
> >KEZINAPLO, KEZIELOJEGYZES, HIBASNAP, ELLENORZOTT,
EGESZNAPOSTAVOLLET_JC,
> >BE_FORRAS, BE_IDO, BE_IRANY, BE_ESEMENY, BE_SPEC, KI_FORRAS,
KI_IDO,
> >KI_IRANY, KI_ESEMENY, KI_SPEC, BE_ELMELETI, KI_ELMELETI, BE_MUNKA,
> >KI_MUNKA, E_KEZI_JC, E_KEZI_KEZDET, E_KEZI_VEGE, E_KEZI_FIX_JC,
> >E_KEZI_FIX_KEZDET, E_KEZI_FIX_VEGE, E_TERMINAL_JC,
UTOLSOFELDOLGOZAS,
> >MRMCSERE_IDO, MRMCSERE_KEZELOAZ, MRMCSERE_PCAZ, MRMCSERE_TIPUS,
> >MRMCSERE_MRAZ, MRMCSERE_SPEC, BIN_DATA, BIN_WORK FROM MI_NAPIADAT
WHERE
> >SZEMELYAZ=:P_SZEMELYAZ AND DATUM=:P_DATUM
> >
> >Result : "SQLDA missing or incorrect version, or incorrect
number/type
> >of variables", and the interbase log: same as the previous.
> >
> >I think MAYBE the varchar(4000) with charset win1250 is the key of
the
> >problem??? Only this two field add to database, before the problem
> >started.
>
> Three questions:
> 1. What is your page size? Is it large enough to accommodate one
record?
> 2. Are you using the proper version of the gds client on all of
the client
> machines?
> 3. Is it coincidence that the column names of your two large
varchar
> columns is BIN_* ? Are you trying to poke binary data into
character
> containers?
>
> Helen
>
> All for Open and Open for All
> Firebird Open SQL Database · http://firebirdsql.org ·
> http://users.tpg.com.au/helebor/
> _______________________________________________________