The ACCESS databases at my workplace can be modified by anyone opening them, which is real scary. Can anyone point me in the right direction to get this protected? Equipment needed? Software changes needed? I thank you in advance for any information.
Maybe I am not understanding the password workings. If I password protect the database, theyn enter the password to have access to enter data...with this access, they can also change forms, reports, queries. Can I change that?
1) Password protecting the database will only stop your people from seeing and changing the database until they know the password. But, once in, they can then change the program.
2) The next thought would be to use the access security wizard to create an Access Security system with multiple user log on accounts. But, unless you spend a lot of time, users will still see the code.
3) The best method to solve your problem would be to compile the access source code (mdb) and that will create an Access (mde) file. Now, this type of file will still work the same as a standard access mdb file, but has no source code available.
If you decide on this method, you should create an access frontend with the programs, forms, reports and queries. Then place your data in a backend access file. Compile the frontend and have that link to the tables in the backend.
Note: Keep a backup copy of your mdb code, becuase you will need that in the future if you need to make cahnages.
The best solution is to combine compiled code in bullet 3 with access security in bullet 2 and if required, use bullet 1 to password protect the backend database only.
Thank you very much! Is there a manual I can purchase to guide me through these changes? Does the FE and BE need to bee on different servers, or differently mapped drives?
The frontend and backend can be on the same server.
Personnaly, I like to place the backend on a shared server.
Then, I copy the FrontEnd to each users local PC.
Now I link the frontend to the shared backend tables.
This method uses the least network traffic, so is the best regarding performance since the code is run from the frontend which is local.
Access itself has a wizard to help you split an access databse into a frontend/backend.
Run >Tools>Database Utilities>Database Splitter
Access error.
I have a database that I am developing for keeping track of students information and progress during a series of classes. I have 4 different forms for entering the information into the underlying tables. These forms have simple control buttons (Find Student, Add Student, and Close Form) that are on each form. For some reason I keep getting this error message:
The expression On Click you entered as the event property setting produced the following error. Network connection may have been lost. The expression may not result in the name of a macro, the name of a user defined function, or [Event Procedure] There may have been an error evaluating the function, event, or macro.
I've tried repairing the compressing and repairing the database. I've started a Blank database and imported all the tables and the forms..... but can't get rid of this pesky error.
Can anyone shed a light on this problem?
Thanks,
1) You may actully have a network drive or linked table that is not available,
but.....
2) This same error is reported when Access can not see the code behind the form or report. So, Access thinks there must be a network error.
Why/How does this happen you ask?
With Access 2000 and later versions, if you import a form, report or module or
If you copy and paste one of these objects or
If you rename one of these objects,
You MUST open up a code window and compile the code. This completes the access copy/import/rename process.
If you do not compile the database, then you may see the error you report.
To fix this, try again by creating a blank database, import all objects and then, first thing, open up a code window and compile the database. You must get a clean database compile.
Once this happens, make a backup.
If this suggestion does not work, then you must import your forms and reports, one at a time and compile. Whatever compiles good, that is a good thing, but whatever still will not work must be imported from an older backup or must be written from scratch.
Remember:
1) Backup often
2) When you copy or past or import a form, module or report, the next step should always be to compile
3) backup, Backup, Bacakup.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.