Hello Alan,

> No matter what I try, I can see that in
> procedure TIB_Statement.SysExecPrepare;
> in IBA_Statement.IMP
> the UPDATE SQL statement for the query in question gets (tries to
> get) prepared. This is where the exception is raised. Setting the
> transaction to readonly and or the query itself to read only does
> not change the fact that the attempt to prepare the Update statement
> is made and the exception raised.

That's too bad, because this means you have to write code to check
this kind of situation and switch off the custom SQL (and maybe switch
it on later if the user is allowed to change roles during execution).
It would be nice if IBO just wouldn't prepare the custom SQL if the
transaction or the query is readonly.

Maybe there's a good reason why IBO behaves as it does at this
point. But if not, we could ask Jason to change this in a future
release. It would certainly save a lot of coding.

> Now, there are lookup combo's attached to this query with the
> appropriate keylinks set to enable editing by the editing role (or
> normal application behaviour)
> When you say "how about the KeySource-Lookup relations " what do you
> mean? Is there some adjustment I need to make to this relation when
> requiring no editing?

I'm not positive you _do_ have to adjust things here. I mentioned them
because the purpose of KS-LU is, after all, to insert and update
data. So maybe having them around would cause IBO to prepare insert
and update statements, causing the same error as the custom SQL did.
But if this isn't the case, so much the better!


BTW: you were correct in assuming that my app doesn't have any custom
SQL. Otherwise I would no doubt have had the same poblems as you.


Greetings,
Paul