Hi Paul,
I've sorted it all out now. I clear all custom SQL for the readonly role.
That works just fine (I mean the final product), and luckily I do not permit
role changing in the same app session, otherwise it would be a real pain as
you say.
I agree, since the Transaction readonly setting is sort of global and since
it propogates to the queries, then surely when you set it, you are doing so
to force no action of updating against the server. So the custom SQL should
not be prepared.
I also could not just set the transaction readonly, since I wanted another
role to have the ability to edit one table in a particular way (i.e. one
field) so I had to clear the SQL and ensure that requestlive was false on
all queries, otherwise IBO would dynamically create update SQL and prepare
that (as I imagine it does for you and you rely on it). I had some
requestlive's set to true which were, of course, being ignored where
customSQL was present. Take the customSQL away and IBO creates the SQL for
you.
Anyway I'd love to hear the full logic behind the need to prepare custom SQL
when the query (or even transaction) is set to read only. It's even more
unwarranted network traffic as far as I can see.

Alan


-----Original Message-----
From: Paul Vinkenoog [mailto:paul@...]
Sent: Saturday, 5 April 2003 9:38 PM
To: IBObjects@yahoogroups.com
Subject: RE: [IBO] Roles & Permissions


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



___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/