 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Modules / DAO / VBA / April 2007Startup Code to disable Shift+Enter
Hello Guys, Could anyone help me with the following issue: I've created a database and secured it thru the user-level security wizard by creating a updates group with password. And certainly myself is in admin group. I need a code or autoexec file which would enable/disable AllowByPassKey property of the database so that only admin group can ignore the startup setting by pressing Shift+Enter, but no updates group users. And could you please also advise where should I place this code if available. Thanks.  SignatureRegards, Fuad Hi, have a look here: http://www.mvps.org/access/general/gen0040.htm SignatureBest regards, ___________ Alex Dybenko (MVP) http://alexdyb.blogspot.com http://www.PointLtd.com > Hello Guys, > [quoted text clipped - 9 lines] > > Thanks. Hi, Alex Thank you for help but I actually knew about this code which is given in the Access help and enhanced in the source you've given. But my concern is where to locate this code within the database so that it automatically runs while the user-level password secured database is launched and will it identify itself wether admin is starting the application or user with the restrictions, or some additions should be made to the code to get this capability. I tried to use CurrentUser property in combination with this code and placed it in separate Module but it did not seem to work. Could you please advise on this issue? SignatureRegards, Fuad > Hi, > have a look here: [quoted text clipped - 13 lines] > > > > Thanks. > Hello Guys, > [quoted text clipped - 9 lines] > > Thanks. You misunderstand how that code works. You need to run it exactly once and it takes effect the NEXT time you open the file (and every time after that). There is no need to run it every time and there is no way to make it "kick-in" for the current session. So... you leave the bypass key enabled on your development copy of the file and you run the code once on the distribution copy just before sending it out to your users. If you want to occassionally gain full access to a distributed copy then you can run code from some obscure location in the app that re-enables the bypass key. SignatureRick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Thank you very much, Rick. I really misunderstood the usage of this code. And last one: does running of the enhanced code that Alex recommended mean that only admin will be able to re-enable the by pass key by the method of running code "from obscure location in the app" as you stated, i.e. application can be considered to be fully "locked" for other users. And could you please just shortly describe the way of the running this code from obscure location. Sorry for annoying you with details, it's first time I do these security things and am absolutely weak on that. Thanks. SignatureRegards, Fuad > > Hello Guys, > > [quoted text clipped - 21 lines] > If you want to occassionally gain full access to a distributed copy then you can > run code from some obscure location in the app that re-enables the bypass key. I did this once by indentifying a specific user in the code. If that user logged in, the code would unlock the bypass key. That is the ony thing I used that user ID for. So to get into the app, log on as the secret user, close the app, then open it again with the shift key down. SignatureDave Hargis, Microsoft Access MVP > Thank you very much, Rick. I really misunderstood the usage of this code. And > last one: does running of the enhanced code that Alex recommended mean that [quoted text clipped - 32 lines] > > If you want to occassionally gain full access to a distributed copy then you can > > run code from some obscure location in the app that re-enables the bypass key. OK, Dave. So then where did you place your code to activate it after the user logged in by his own ID (or password). And you seem to have used CurrenUser property to identify the logged user... SignatureRegards, Fuad > I did this once by indentifying a specific user in the code. If that user > logged in, the code would unlock the bypass key. That is the ony thing I [quoted text clipped - 39 lines] > > > If you want to occassionally gain full access to a distributed copy then you can > > > run code from some obscure location in the app that re-enables the bypass key. Put the code in the Load event of the form that opens when you open the app. SignatureDave Hargis, Microsoft Access MVP > OK, Dave. So then where did you place your code to activate it after the user > logged in by his own ID (or password). And you seem to have used CurrenUser [quoted text clipped - 43 lines] > > > > If you want to occassionally gain full access to a distributed copy then you can > > > > run code from some obscure location in the app that re-enables the bypass key. Give yourself some backdoor within the app. Clicking on a header logo for example. In the click event for that logo, check the user's priviledges (or ask them for a separate password), if they pass the test, run the code to enable the bypass. Display a message box telling the user that they need to close & reopen the app with shift pressed to gain full access. If you do this, you should consider adding a line of code to whatever code runs from AutoExec (this is the code that gets bypassed when your DB opens) that DISABLEs the bypass key every time it runs. That way, once someone enables the bypass, it will automatically be disabled the next time anyone opens the file without holding down Shift. Avoids the risk of leaving the bypass enabled simple because someone forgot to turn it back on. Because that someone will eventually be you :-) HTH, > Thank you very much, Rick. I really misunderstood the usage of this code. > And [quoted text clipped - 44 lines] >> run code from some obscure location in the app that re-enables the bypass >> key. Thank you very much guys !!! I really appreciate your help and now I'm thoroughly confident in what I should do owing to your valuable recommendations, and thanks again. SignatureRegards, Fuad > Give yourself some backdoor within the app. Clicking on a header logo for > example. [quoted text clipped - 63 lines] > >> run code from some obscure location in the app that re-enables the bypass > >> key. > Thank you very much guys !!! I really appreciate your help and now I'm > thoroughly confident in what I should do owing to your valuable > recommendations, and thanks again. The "back door" that you're advised to allow should just be "extra insurance". The best advice you got in this entire thread is to maintain a development copy which does allow opening with the bypass key. For convenience in maintenance even if it is a single-user application, and extreme convenience in deployment if it is multiuser, you should have the front-end (aka user interface: queries, forms, reports, macros, and modules) in a separate database, with each user having their own copy... that "production copy" is the one where you "button down" the security and need to use the options for allow/disallow bypass key, and the back-end (with tables, relationships, and data) in a separate database in the same or shared folder. Tables in the back-end will be linked from the users' front end databases, so you can update the application and provide a new copy to the users without having to transfer/manipulate the data. Larry Linson Microsoft Access MVP Yes, Larry, it's good decision...I'll follow your recommendations, thank you very much. SignatureRegards, Fuad > > Thank you very much guys !!! I really appreciate your help and now I'm > > thoroughly confident in what I should do owing to your valuable [quoted text clipped - 17 lines] > Larry Linson > Microsoft Access MVP |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.