Subject | Re: [IBO] Re: Prepare in IBquery - Help me!!!! |
---|---|
Author | Carlos H. Cantu |
Post date | 2001-01-02T15:02Z |
ND> If the statements are prepared every time they are needed, this would
ND> surely be inefficient. A better solution would maybe be to prepare each
ND> statement the first time it is needed; this would solve the problem and
ND> also help reduce resource usage, I think. Dunno if it is easily doable,
ND> though.
I already talked in private with Jason about this... we are trying to
figure out a way to find a diferent handle to this situation without
breaking currently software/people concepts.
Jason told me that the reason of ALL the stataments being prepared when the
Query is opened is because some IBO controls (Like IB_UpdateBar, etc...)
needs to know if the user can insert/update/etc...
[]s
Carlos
WarmBoot Informatica - http://www.warmboot.com.br
Interbase-BR - http://www.interbase-br.com
ND> Claudio,
ND> not before. This way, he can deploy a single application and rely on
ND> GRANT/REVOKE only to customize the access.
ND> surely be inefficient. A better solution would maybe be to prepare each
ND> statement the first time it is needed; this would solve the problem and
ND> also help reduce resource usage, I think. Dunno if it is easily doable,
ND> though.
ND> you want to deploy the same application to different categories of
ND> users; I wouldn't do it; your solution will certainly work but it's
ND> cumbersome and leads to multiplication by 4 of the number of data access
ND> components needed in the application.
ND> At the very least, an event that signals a prepare error, whose handler
ND> gets passed the kind of statement (edit, insert, update...) could help.
ND> I'm curious to know what Jason thinks about this one.
ND> Regards
ND> surely be inefficient. A better solution would maybe be to prepare each
ND> statement the first time it is needed; this would solve the problem and
ND> also help reduce resource usage, I think. Dunno if it is easily doable,
ND> though.
I already talked in private with Jason about this... we are trying to
figure out a way to find a diferent handle to this situation without
breaking currently software/people concepts.
Jason told me that the reason of ALL the stataments being prepared when the
Query is opened is because some IBO controls (Like IB_UpdateBar, etc...)
needs to know if the user can insert/update/etc...
[]s
Carlos
WarmBoot Informatica - http://www.warmboot.com.br
Interbase-BR - http://www.interbase-br.com
ND> Claudio,
>> Ans what do you expect? That IBO guesses that the user has no privileges?ND> maybe he expects to get an error message when the user tries to update,
>> :-)
ND> not before. This way, he can deploy a single application and rely on
ND> GRANT/REVOKE only to customize the access.
>> IBO prepares the statement in advance, for efficiency.ND> If the statements are prepared every time they are needed, this would
ND> surely be inefficient. A better solution would maybe be to prepare each
ND> statement the first time it is needed; this would solve the problem and
ND> also help reduce resource usage, I think. Dunno if it is easily doable,
ND> though.
>> I don't know if you plan to query system tables to see if some user isND> In the current situation, you are *forced* to query the system tables if
>> allowed to modify data. How did you expected this to happen? Black magic?
ND> you want to deploy the same application to different categories of
ND> users; I wouldn't do it; your solution will certainly work but it's
ND> cumbersome and leads to multiplication by 4 of the number of data access
ND> components needed in the application.
ND> At the very least, an event that signals a prepare error, whose handler
ND> gets passed the kind of statement (edit, insert, update...) could help.
ND> I'm curious to know what Jason thinks about this one.
ND> Regards