Startup Properties question

[shar]

The startup properties from the help file let you secure the db so users cannot get into design mode, or press the shift key to bypass the autoexec, etc.<br><br>I set the following properties for my db to secure it:<br><br>ChangeProperty &quot;StartupShowDBWindow&quot;, dbBoolean, False<br>ChangeProperty &quot;StartupShowStatusBar&quot;, dbBoolean, False<br>ChangeProperty &quot;AllowBuiltinToolbars&quot;, dbBoolean, False<br>ChangeProperty &quot;AllowFullMenus&quot;, dbBoolean, False<br>ChangeProperty &quot;AllowBreakIntoCode&quot;, dbBoolean, False<br>ChangeProperty &quot;AllowSpecialKeys&quot;, dbBoolean, False<br>ChangeProperty &quot;AllowBypassKey&quot;, dbBoolean, False<br><br>Once these properties are set, how can I get into the system to make changes?&nbsp;&nbsp;With these properties set, it seems there is no way to get into database window to work in modules, forms, reports, ...<br><br>Is there a way to set these, and yet leave a door for the programmer to get in for modifications.<br><br>Using the Access security is not an option, as we use Novell as our NOS.<br><br>Any input is appreciated.&nbsp;&nbsp;Thanks.<br>Shar

 

[Amiel]

<br>I typically use an Environment Variable like: USERNAME<br>and execute the code conditioned on its contents<br>as in:<br><br><br>if Environ(&quot;USERNAME&quot = &quot;myname&quot; then<br>&nbsp;'don't lock the mdb<br>else<br>&nbsp;'code to lock it.<br>endIf<br><br>You could of course add an additional environment variable<br>(and id' suggest that you do) just in case your logon gets changed in the future.<br><br><br><i>...ask me how a user might get around this.</i>!<br>Have fun.<br><br> <p>Amiel<br><a href=mailto:amielzz@netscape.net>amielzz@netscape.net</a><br><a href= > </a><br>

 

[JimConrad]

You could create a macro or module function to set AllowBypassKey to False.<br><br>Make a copy of the database BEFORE setting the value to FALSE.<br><br>You do NOT need to set this property more than once.&nbsp;&nbsp;So it doesn't need to be part of an &quot;Autoexec&quot; macro.<br><br>This gives you a copy for developing and a separate copy (which your users can't modify) for production use. <p>Jim Conrad<br><a href=mailto:jconrad3@visteon.com>jconrad3@visteon.com</a><br><a href= > </a><br>

 

[Amiel]

<br><br>Sure, but beleve me I've already experienced it. And more than once. After you've mistakenly locked yourself out of a module that you've been working on all day (or for weeks) because you overlooked a step in this routine you'll come to appreciate the value in the approach that I've suggested.<br><br>These few lines of code are a small price to pay in comparison to loosing all of your work.<br><br> <p>Amiel<br><a href=mailto:amielzz@netscape.net>amielzz@netscape.net</a><br><a href= > </a><br>

 

[shar]

Thanks for both suggestions.&nbsp;&nbsp;I kind of thought JimConrad's way was the only way around this and I have been wary about locking my self out accidentally.<br><br>Amiel:&nbsp;&nbsp;I am not sure what you mean or how to 'code to lock it'.&nbsp;&nbsp;I do have the user names in a table within the db which evaluates their rights upon startup.&nbsp;&nbsp;However, the more knowledgeable users can press the shift key, bypass the startup evaluation codes, and go directly to the tables.<br><br>Does your method prevent this?<br><br>Thanks.<br>Shar