So your distributed database will have to match what you have supplied in your application (above).  You set this in the project settings of your security project.

If these two things do not match, all of your users will be inaccessible and you will not be able to use them.  One easy way to tell is that your user icons will be different when you open the SecurityDialog from within your application.  If you do not have this setting correct, that will be short little blue guys and when you click the user, it will show an error in the right panel indicating that the user is not valid (or something along those lines).

Adding the "Security Basics" patch code line did solve the problem.  I don't know what data for the application that you are referring to ... The use of the "integrated" Administrator and "integrated" Security Maintenance users should not require any "security" data to be set up for them ... There is no reference to them when you populate the security tables with user / role / permission / restriction information.

And I did verfify that the "security key" information matches ...

I think that maybe you still do not understand my problem ....  With the sample application that I posted, the integrated Administrator user works just fine ... no problems at all .... can access the Security Forms as expected .... BUT without adding the patch code line suggested in the previous post above,  the integrated Security Maintenance user can not access the Security Forms ....  You get an "Access Denied" message when you try to show the Security Forms dialog ....  After adding the patch code line, and not changing anything else ... the Security Maintenance user is able to access the Security Forms dialog as described in the documentation and samples ... just like the Administrator user can do before adding the patch code for the Security Maintenance user ...

There is something in the Strataframe code that will not let the integrated Security Maintenance User have access to the Security Forms without adding the patch code to an application.  This patch code has worked on every application that I have tested so far ....  WITHOUT the patch code ONLY the Administrator user can access the Security Forms ... BUT with the patch code BOTH integrated users can access the Security Forms ....

If you DO NOT add the patch code and use the integrated Administrator user to add Application Admins to the security table and give them "Administrative" rights when you set up the Application Admins, they ALSO can access the Security Forms without any problems ....  the only problem is with the integrated Security Maintenance user if you do not add the patch code suggested in the previous post ...

Does this information help explain the problem any better?

Here is the short (and hopefully simplified) version of what I discovered with Greg's assistance:

1) In the Strataframe source code,  the "SecurityMaintenanceKeyPrefix" property is given a default value of "Security_"

2) In the Strataframe source code, the "Security Dialog" form is given a default "Security Key" of "Security Editor"

3) The integrated Maintenance Security User is granted security to objects based on the "SecurityMaintenanceKeyPrefix" value ... in this case "Security_"

This means when the integrated Maintenance Security User is logged into your application, any objects which are defined with a "Security Key" property value that STARTS WITH "Security_"  will be issued the "GRANT" permission for that object and allow the integrated Maintenance Security User access to that object

This is where the problem is created .... everything matches in the 2 character text strings through the word "Security" but the next text character is causing the Strataframe Security System to issue the "DENY" permission for the object (which is the Security Dialog form) because the prefix value is looking for an "_" (underscore character) as the next text character in the evaluation of the Security Key value for the object BUT the object (Security Dialog form) has a " " (space character) as the next text character and this DOES NOT MATCH !!!!!! 

Therefore, the integrated Security Maintenance User is denied access because of the mismatch between the space character and the underscore character.  Greg's patch code suggestion of adding a code line in the program.cs file to "redefine" the "SecurityMaintenanceKeyPrefix" to be "Security " ... works because this makes the " " (space character) after the word "Security" match in the prefix value and the object Security Key value.  As Greg also suggested, I have tested changing the "SecurityMaintenanceKeyPrefix" value to just "Securty" and this works just fine also BECAUSE the Strataframe Security System is matching the text characters from the "SecurityMaintenanceKeyPrefix" and the object "Security Key" for the length of the "SecurityMaintenanceKeyPrefix" text string.

A future fix for the Strataframe Source Code would be to change the default value for the "SecurityMainenanceKeyPrefix" or change the default value for the "Security Key" for the Security Dialog form  SO THAT they will both have the same "Starting" characters for the length of the "SecurityMaintenanceKeyPrefix" text string.

Trent, can this be done in a future release version ?????

A BIG Thanks goes to Greg McGuffey for helping me work through and understand this problem and the required solution.