Member_2_8206019
asked on
Lotus script "RunOnServer"
Sorry this is a basic question. I'm a new for Notes. I have lots of unclear points...
In Notes, there are two DBs, DB "A" and DB "B". A user have an ACL for DB "A" but not DB "B".
When the user clicks a button in DB "A", I'd like to run an agent to update some data in DB B.
I feel this can be done by "RunOnServer". The agent will be run with 'Server' ACL. This server have a ACL fpr DB "B".
Is this my approach correct?
In Notes, there are two DBs, DB "A" and DB "B". A user have an ACL for DB "A" but not DB "B".
When the user clicks a button in DB "A", I'd like to run an agent to update some data in DB B.
I feel this can be done by "RunOnServer". The agent will be run with 'Server' ACL. This server have a ACL fpr DB "B".
Is this my approach correct?
Steve Knight
Does the data need updating in the other dB immediately? You could schedule an agent on the other database to refresh is data for instance otherwise?
ASKER
Yes, I need to update the data immediately. I tested the RunOnServer. The agent seemed to work with the signer's ACL and could update the data in other DB. Is there any issue in this approach?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for reply. In the current my case, the updater's name is not important. I understand this approach is basically no problem.
I feel like the March Hare...
Sorry Steve but I think my approach is better. Allowing to kick off an agent in another database directly should be avoided IMHO. What then? Simple: send the other database a mail!
Sure, there are some disadvantages (less direct, requires mail-in database settings, and some additional programming), but these are outweighed by the advantages: no knowledge required of the other database except for its mail name, prepare a "command" and send it out, with info (arguments), no ACL changes, simple agent on after mail is received (or before), everything above board. It's like simply triggering the other database.
Sorry Steve but I think my approach is better. Allowing to kick off an agent in another database directly should be avoided IMHO. What then? Simple: send the other database a mail!
Sure, there are some disadvantages (less direct, requires mail-in database settings, and some additional programming), but these are outweighed by the advantages: no knowledge required of the other database except for its mail name, prepare a "command" and send it out, with info (arguments), no ACL changes, simple agent on after mail is received (or before), everything above board. It's like simply triggering the other database.
Sjef, that is what i often do with a transaction database processing requests which are then processed across multiple DBs. I do use run on server for some things, without knowing the app difficult to know which way would work best.
Steve
Steve
Of and i think the idea was the agent ran on the same database on the server but it accessed the second database.
I agree, it's only that I prefer to send the other DB a request and let it handle the request all by itself. But if there's some sort of hierarchy between those databases, I can understand that one database has control over the other and one gives preference to using an agent in the current database to modify the other.
I even have databases that send themselves messages, in order to decouple or defer execution.
I even have databases that send themselves messages, in order to decouple or defer execution.