A few days ago, I wrote a procedure which invokes a screen (form) from which data is collected, then handled in later stages of the procedure. I wrote about something similar here; this time, there was no need to define a file parameter. The twist this time is that the form has a sub-form from which the data is collected. It took me a while to wrap my head around this, but eventually I figured out how to make the form do what I wanted it to do.
Flushed with success, I added the procedure to menu A (this allowing other people to use it) and told a colleague where to find it. The colleague telephoned me in short order, saying that he could see the top-level form, but not the sub-form. As the sub-form is key to the procedure, this was quite a blow.
Normally it is enough that a person has permission to run a procedure; that permission will cover everything included in the procedure. Apparently not so in this case. The problem was originally solved by adding the top-level form to menu B and giving the user permission to use it; this is not ideal, but isn't too bad as for reasons which are not relevant, running the form outside of the procedure does nothing.
Still, the permission problem bugged me. The consultants who support my company came up with an idea: don't change any permissions, but instead remove the form from menu B. This way, the permissions table might be tricked into keeping the permission. And indeed this works. Strange but true.
3 comments:
Something else which might work rather than "tricking" the permissions system:
Add an END step at the end of the procedure and then another step with the parent form.
Something else which might work rather than "tricking" the permissions system:
Add an END step at the end of your procedure and then after that the upper input form.
I doubt that this suggestion would make a difference, as the parent form was displayed. Maybe adding the sub-form at the end would do the trick.
Post a Comment