At 12:01 AM 14/07/2005 +0000, Adam wrote:

>I believe STATE is a reserved word. We had to name our table states for
>that reason.

It's true; and it's a fact that the SQL statement is wrong and therefore
could be expected to throw a conventional ISC exception.

The problem here is that it's not throwing an exception, it's crashing the
application instead, with a memory access violation.

Furthermore, when an ISC error *does* appear, it is the wrong one. That
indicates at least that the wrong message file is being read.

So there is more going on here than meets the eye. I would suspect that
it's environmental. That the embedded app and various full server clients
(tools, user apps) are being run on the same machine, with confusion about
the version(s) of the client library that each is loading and accessing.

Three pieces of advice here:

1. Correct the SQL and make sure that all SQL statements - those you
define and those that the data access interface generates - are squeaky
clean. This part will eliminate invalid SQL exceptions -- when you finally
get your client pieces properly sorted out.

2. Go to the IBO list and ask what you have to do to ensure that your
embedded app loads the right client library. If it's a requirement for you
to run your embedded module on a machine that's already set up to load a
different client library that has the same name, then you're going to need
to do more than you have done so far to keep these elements apart.

3. Again - an application issue, not a Firebird one - is whether you are
using a version of IBO that recognises quoted identifiers, knows what to do
with parameters for Firebird databases, etc. Old IBO versions, written for
ODS 9 and lower servers, will throw wobblies on encountering some of these
things. Again, issues to ask about on the IBO list, not here.

./heLen