At 08:52 AM 8/11/2005 -0800, you wrote:

>Hello:
>
>Have a bug that I can't figure out and hope someone can lend a hand:
>
>Getting
>
> ISC ERROR CODE 335544333
>"Internal gds software consistency check (can't continue after bug
>check)"
>
>Using FB 1.5.0.3744 with IBO

Yikes, that was an old beta from August 2003. You gotta be kidding! There
were four further betas between that one and the release of v.1.5.0.

>for the following
>
> with qryUpdate do
> begin
> IB_connection := cnIBImport;
> Close;
> SQL.Clear;
> SQL.Add('SELECT rdb$field_name as Field ');
> SQL.Add(' FROM rdb$relation_fields ');
> SQL.Add('where rdb$relation_name = :TableName');
>=> ParamByName('TableName').AsString := TableName;
> Prepare;
> Open;
>...
>
>end;
>
>I call this routine many times in my data update wizard (for each table)
>and so far have not had this error ever come up. I use it for creating
>the SQL for Select, Insert and Update.
>
>The "ParamByName('TableName').AsString := TableName;" is what causes the
>error.
>
>The same code if run as a query against the same table inside IB_Expert
>or IB_SQL runs fine, without error.
>
>Thank you for any help to eliminate this bug.

The *FIRST* thing to do is replace that old beta with the latest production
version (currently Fb 1.5.2, though 1.5.3 is close to releasing...) That
"...after bugcheck" error shouldn't ever be seen by production
clients; but it was a bug exhibited duing those late betas.

I wonder then whether you are also using a really old version of IBO, that
won't predictably do the right thing with parameters, due to an old
InterBase bug that the old versions of IBO do a workaround for. From IBO
4.3 forward, a check is done at connection and IBO does the right thing
depending on whether it's looking at a Firebird 1.5 database or something else.

Also, you DO need to use the correct client library. If my memory serves
me correctly, at that point in the 1.5 beta we were using a redirection
hack on Windows to get applications to use the correct library. All this
stuff was replaced at around RC 8, so you client side probably isn't pukka.

On the application side you should put a TIB_Monitor on cnIBImport and see
the actual value that IBO is passing in that parameter each time. If other
table names seem to work and that particular one (MASTERLIBRARY) causes an
unidentifiable error condition, it's the only way you're going to find out
what's happening.

I also wonder why you have to assign IB_Connection every time you run
it; and why you think you have to assign the SQL and prepare the query
every time. If it's because this snippet came from some code that actually
creates and destroys qryUpdate each time it is used, then you have some
stuff missing, or at least prone to being unreferenced. (This is
definitely an IBO/Delphi good/bad practice issue though, off-topic here.)

And a where clause that resolves to

WHERE RDB$RELATION_NAME = NULL

will certainly cause an exception ("= NULL" is a valid SQL
predicate!); though it should be a DSQL exception, not an anonymous
bugcheck error. Could be that it's not MASTERLIBRARY that causing the
exception at all, but a case of your application reaching EOF in the set
that it's reading the table names from. I have this creepy suspicion that
this set might be a tibotable object and you're actually reading the
TableName property....aaargh!

Get rid of that beta! And make sure you cover the bases
(OldParameterOrdering=1 activated in firebird.conf) if you are using a pre
4.3 version of IBO.

./heLen