The front-end application should not "hard-code" security administration into the application. Instead, the system as a whole should be secure regardless of whether or not a user has access to a client executable. When security administration is performed on the server, the client applications should adjust dynamically to reflect these changes, enabling and disabling controls that correspond to server functionality. Code should never have to be recompiled because security administration has taken place.
The GUI facilitates calls to server-based stored procedure business functions. The fact that the GUI enables or disables controls depending on the logon is merely convenience and good interface design. However, even if a user manages to get access to a control they shouldn't, the security of the system will not be compromised. In addition, security and database integrity is not compromised even if a user attempts to invoke business functions from other tools (e.g. Microsoft Access or ISQL).
When several stored procedures are associated with one business function, SQL Server user groups should either be given access to all its SPs or none. It is safe to assume, therefore, that the front-end need only to check the first SP for access to determine whether or not the user has permission on a particular business function.
If a user does not have access to any business function of a MDI SnapShot child form, it is best to disable the control on the SnapShot Manager form that initiates the load of the child form.