I wouldn't use the switchboard. The switchboard 'wizard' creates a table and the switchboard form is then bound to that table. On Main Menu type forms, it's good practice to keep this form 'unbound' from any recordsource. Reason - since user's typically keep the Main Menu form open, you really don't want this form bound to a table as this can eventually cause the mdb (ie. the associated *.ldb file) to become 'locked' for other users.
Instead, design a form without the wizard (and don't put in a recordsource for the form's property) and then just add buttons to the form to open your other forms. You typically want any non-data type forms unbound from any recordsource. Especially if you anticipate (such as with a Main Menu), that the user might keep this form open for a long time.
Personally, I think the switchboard is the worst feature MSAccess ever designed.
If you want to setup a user/password permissions type system, you may want to look at this example: http://www.dbforums.com/6332819-post68.html
Basically it involves creating a 'user' type table that holds users loginID's and has a field in the table which determines their 'security' level for each user. Then using the 'getuser' method (in the example) to automatically retrieve the user's loginID, you do a lookup to the 'user' table to retrieve their security level. For example, on a button in the Main Menu to open a 'data' type form, you'd add 1 or 2 lines of code in the button's OnClick event to lookup the user's security level and then open the data type form in a read-only or non-read-only type view (as the example demonstrates). I use the 'getuser' method to retrieve the user's LoginID in all my applications. It works very well and prevents users from having to enter their loginID (username)/password since it's all automated behind the scenes. I found users tend to get tired of always entering their username/password.
It does require a bit of knowledge with vba coding but otherwise, it's fairly straightforward.
Your other option is to setup MSAccess security itself on the mdb. Most new MSAccess developers though find MSAccess security to be trouble-some to work with and I'd test this method on an example mdb first versus a live one. If not done correctly, you can find yourself locked out of the mdb.
Last edited by pkstormy; 03-20-10 at 15:31.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)