I have a split db with tables in the back end and my forms, reports, code etc. in the front end.
I encrypted the back end with a password. That worked fine.
I deleted and relinked my tables to the encrypted back end. That worked fine as well.
I have a function that will disable the shift key bypass. If I run that in my front end db then I can't save it as an accde because I can't get to the HOME screen. If I save it as an accde first then I can't run my 'disable shift key bypass' function because I can't get to the modules!
How can I secure a split Access 2010 database so that the user cannot execute shift bypass on the front end or make any changes to the code?
I don't have the database finished so I can't really comment on the structure. However, I know the database will be used by multiple people, very likely at the same time. I've heard it's a good idea to split the mdb into a frontend and a backend so I've already started that process. I have no idea how this would fit into a security scheme though. Do I have to set up user-level security on both ends? Without actually implementing it I kind of think it would be secure if the backend had a master password and the frontend had user-level access. What do you all think?
I have a access 2010 split database and i need to modify one form on the front end (it is an accde file). However, when i open the Front end, i cannot find the possibility to go into the form design mode.
How do i need to do it? do i need to restart from the unsplit database?
The both the front end and the back end are password protected.
I have built an Access 2010 split database on my computer and it functions as built. My next step was to copy it to the server at work and test it. I discovered the tables had to be re-linked and so did that. As I have read in the Access World Forums in order to function as a multi-user database a copy of the front end must be placed on the individual workstation with the back end residing on the server, however the hyperlinks in the back end will not function when the copy on the workstation is run. I simply get an unable to open "filename" error pop-up. I can run the server copy and everything functions as built. I know that the hyperlinks require all the files to be in the same folder (relative vs. absolute), but if the back end contains all the hyperlinks why does the location of the front end seem to affect the operation of the back end?
This is my 2nd thread on the topic...I've searched the forums....
I have a database. It is on the shared folder on the server. I ran the security wizard and created a shortcut. On my machine it works perfectly...asks for a login, has a couple user groups etc...
When I run it off the server though, the shortcut doesn't work....refers to files on my machine?? and the database is unsecured.
Do I have to run the security wizard on every machine? Do I need to run the security wizard from the server? Or do I even need to run the security wizard at all??? My 2-day access course is failing me miserably...
Is it possible to have a value in an excel 2010 cell be used to update an access 2010 db?
For example, if in a spreadsheet "test" cell A2=3 then in a db "test" a column "value" is 3. However, if the value in the spreadsheet changes so does the db.
I have been doing an exercise to split the data from the list of the information into column A, B & C. Unfortunately the data value that i have consist of several set of data format therefore it create an issue for me to separate the information in Access 2010 easily.
eg.
Original Data Field FLRY-B-0.75-L-GY FLRY-4.0-V-R VTAC-GY 19X20 COT-F2-5-DL
Actual Data To Populate Into Column A, B & C should be the following :
I have designed a database which I intend to split for multi-users to access from one front end icon on a shared folder at work. I have designed a form bound to cmr record table and on it a subform to another table where cmrs activities will be saved. The form has buttons to and blank controls.
User can create a new activity entry by typing into the blank controls and pressing the save button which saves to the activity table. the edit button extracts a selected records details (selected on the subform) from the activity table and populates the blank field for a user to edit and then hit save to save changes. The delete button deletes a selected record from the activity table. I intend to have multi-users either accessing, viewing and a possibly editing the same customer at the same time. The simultaneous viewing is essential but the simultaneous editing, though not desired is inevitably going to occur.
What I would like to know is:
1. Can you lock an individual record in a table or does the whole table have to be locked. E.g If Colleague 1 is editing Cmr A's record in Table1 can he lock it so Colleague 2 can view and edit Cmr B's record in Table1
2.Can Colleague 1 access/read Cmr A's record in Table1 to retrieve details toe the form controls if Colleague 2 is viewing or editing Cmr A's record in Table1
3. If record lock is possible, how can I initiate it in my example code below.Edit activity record Code
Code: Private Sub Edit_A_Click() 'Get Data to text box control With Me.R_P_Data_P_Subfrm.Form Me.txtrID = !rID Me.txtrID.Tag = !rID Me.txtrefNo = !refNo Me.cmbrpc = !rPC
Is there a way of changing the column heading names on the split form portion of an access form. I tried changing them using a query to populate the form and changing the caption of each field in the query and that didn't work. I also tried adding a [Caption] at the design level of the table and that had no affect also. The split form seems to be displaying a portion of the actual field name or something like that.
I have two questions. All of my experience has been in Access 2003. My work just upgraded to 2007. I am ready to secure a database that I have now converted to a 2007.
1. Is it possible to set the db to open as read only for everyone on staff except for a few people?
2. How do I set security levels where some can view all tables and others can only view specific tables?
For example, I only want 2 people to be able to modify any data. And I don't want anyone to view the accounts receivables, but they need to see other data on the customers.
As I promised earlier, here is my suggestion to secure an MS-Access database. The explanation below is applicable for MS-Access 2000 and XP versions, I haven't tested it on Access 2003.
This way of securing a database is a bit different from the one I posted earlier, but more secure.
Disclaimer: This explanation of securing a database is based on MY experineces. I mean I've been doing it in this way, and it worked OK for me. I DO NOT say that there is no other method of securing a database. I will NOT take responsibility for any problems caused by securing your databases either in this or in any other way. Use this guide on your own risk.
Pre-reading notice: Menu paths and commands may be different in the English version of MS-Access. I use Hungarian MS-Access, but I am doing my best to remember (or translate to) the English menus and commands. Where I'm in doubt about the exact English menu path or command and there are more than one possible translations, I enclose the alternative between parentheses. Menu paths are indicated like this: File -> Get external data -> Import... Command buttons are indicated like this: <OK>
To secure a database: 1. close the database you want to secure. BEFORE closing it: - If a database password is set, then clear it. - If the VB Project is protected then unprotect it. To unprotect the VB Project go to Tools -> [project_name] options... in VB Editor and click the Protection tab. Remove the tick from the 'Lock Project from viewing' check box and clear the password. 2. CREATE a new blank database; 3. Check and make a note of the path of the default Workgroup Information File (.mdw). - to do this, go to Tools -> Security -> Workgroup Administrator, and read the file path indicated. 4. create a new .mdw file using the Workgroup Administrator, and stay joined to it. - to create a new Workgroup Information File go to Tools -> Security -> Workgroup Administrator, and click <Create...>. Provide the required information, click <OK>, click <Browse...>, and type a name. - I usually use the name of my database which I want to secure. - Note: if you wish your .mdw file to be unique, then you need to provide a workgroup code. - If you provide a workgroup code, it's strongly recommended to make a note of and keep it in a safe place. Should the the .mdw file be lost, you will need this information to create the "same" .mdw file. 5. create a User with your logon name and put this user to the group called 'Admins'; - to create a new user go to Tools -> Security -> User and Group accounts... Click <New...> on the Users tab. Type a logon name, and a PID. - Note: users are identified by their PID, not by their logon name. Anytime you create a user, it's strongly recommended to make a note of the PID and keep it in a safe place. Should the the .mdw file be lost, you will need the PIDs to create the same users in a new .mdw file. - It's enough to create a user account for yourself. You can create the other users' after the whole process. - Don't forget to put yourself into the 'Admins' group. 6. Create a password for the default Admin user (which you are at the moment). - To enforce users to provide a logon name and a password, you need to set a password for the default Admin user. If the default Admin user has a blank password (in other words: no password set for it), then Access automatically starts with the default Admin user, and does not require user authentication. - To create a password for the default Admin user, go to Tools -> Security -> User and Group accounts... and select the Change Password tab. Leave the Current Password blank, then type & confirm the new password. - The default Admin user does not need a difficult password, because this user will not have any permission on the secured database at the end. We need the password only to enforce user authentication. 7. Close the database. 8. CREATE an OTHER new blank database. - If a password has been set for the default Admin user, it will prompt for a password. - Delete the "Admin" and type the user name you just created. NO PASSWORD REQUIRED for this user, so just click <OK>. - From now on, you are logged on as the user that you've just created. Note: if you haven't put this user into the Admins group, you won't be able to continue. - IMPORTANT NOTICE: the reason of creating an other blank database instead of just doing the whole process WITHIN the database to be secured, is that the only way to take the ownership of a 'Database' object is to create it as YOU, and not as the default Admin user. As I experineced, 'Database' ownership CANNOT BE TAKEN AWAY from the creator of the 'Database' object. 9. Go to Tools -> Security -> User and Group accounts... and REMOVE the user 'Admin' from the 'Admins' group. - Clck Users tab, and select 'Admin' from the drop-down list. Select 'Admins' in the list box 'Member' ('Member of'), and click <Remove>. - If you haven't added the new user to the Admins group, then you won't be able to remove the default Admin user from the Admins group because Access will not let you to have no users in the Admins group. At least one user must be in Admins group. - If you can remove the default Admin user from the Admins group, then, from now on, you are the only user with administrative permissions for this database and in this .mdw file. 10. Set a password for yourself. - How? See point 6. - Memorize your password, because it can only be retrieved by using certain Password Recovery processes and softwares. As far as I know, there is NO WAY to retrieve a password via VBA or MS-Access for a normal user, it needs someone with deep hacking knowledge... 11. Import all objects from your database that you want to secure. - Go to File -> Get external data -> Import..., and browse to your database. - Select ALL objects: tables, queries, forms, reports, macros and modules, and click <Import>. - If you haven't unprotect the VB Project, it WILL NOT import any VB code even behind the forms. - From now on, the owner of the 'Database' object and all tables, queries etc. is YOU. 12. Run User Level Security wizard and make the permission settings. - It's recommended to select all objects and grant only data modification rights to the 'Users' group. - After running the wizard, it's recommended to restrict all rights of the default Admin user manually. This will ensure that if your database is opened with the default system.mdw file (which is automatically created when MS-Access is being installed), then the default Admin user will not have any permission to any data or object. 13. Join to the default Workgroup Information File, and close the database. - to do this, go to Tools -> Security -> Workgroup Administrator, and click <Join...>, click <Browse...> and navigate to the default .mdw file you've hopefully made a note of.
After this process, if you just open your secured database then you will open it as the default Admin user. It will not require a password, because in the default .mdw file, the Admin user does not have a password. And, if you've restricted all permissions of the deafault Admin user, you won't be able to make any data or design modifications, and even open any objects. The reason of it is that the default Admin user's PID is the same in all .mdw files. The default Admin user is automatically created when you create a new .mdw file. The default Admin user also CANNOT BE deleted. The default Admin user uses the same PID everywhere, so regardless of how many .mdw files you have on your system, Admin user logically is the same for all databases.
So then how to open your secured database? You need to use the .mdw file you created. So open your database with the /wrkgrp switcher. Create a shortcut and use this in the Target field:
If you open your secured database in this way, then it will require a password (of course, because the default Admin user in your .mdw file has a password). Log on as yourself, and you now can add other users.
NOTE VERY CAREFULLY: 1. BEFORE starting the whole process ALWAYS make at least one backup copy of your unsecured database. 2. NEVER delete this backup copy UNLESS you're ABSOLUTELY SURE that everything is approved and tested and IS WORKING OK in your secured database. 3. DO NOT LET anyone to make any changes in data or design in your backup copy until you're absolutely sure that everything is working OK. Otherwise your backup copy will not be anymore a clone of your database.
Other notice: I've been blocked out from my own databases many times while I was searching for a right way of securing. Unfortunately, HELP provides a likely poor aid.
If you encounter problems, I'll do my best to help you as my time allows me to.
I kindly ask the members that feel themselves more or less experienced to make a test and post any notes/suggestions/bugs/mistakes to this thread, PLEASE.
REMEMBER: IF YOU HAVE A BACKUP COPY YOU WON'T GET TROUBLE.
Have created a database that will be placed on a shared drive, giving access to others to add, delete, modify records. That aspect of it is fine -- but how to I prevent someone from deleting a field?
I am using Access 2010 in a split database. The intent is to place the back end and associated linked files on a server and the front end on work stations for each user. The typical user will just be searching for information in the database not altering it. My current code re-links the tables once the path is known i.e. I have to hard code it into the global constant. Is there a way in VBA or utilizing VBA to read/write to an ini file (for example) that the UNC path would automatically be updated to a global constant in my current code that can be updated automatically based on where the back end is installed.
Global Const BE_DATABASE = "192.168.2.3FMCENFMCTABLES.accdb" Global Const BE_PASSWORD = "***********" Global Const BE_DATABASEPATH = "192.168.2.3FMC" 'used to open files Public Sub CreateDatabaseLinks() On Error Resume Next 'new Dim ws As DAO.Workspace Dim db As DAO.Database Dim td As DAO.TableDef
for our company we have an access application we use to keep track of our customer-info.
The databse consists of 3 parts: The (replicated) frontend The databse holding the changing data The database holding the unchanged data (lookup db)
We have the following problem: somewhere in our front-end db is a bug that allows users to change the contents of the lookup db. In our case this can result in a major problem because the users are able to change the city-zip code table. I have tried to figure out where things go wrong but so far no result.
We have picked up the idea of making the lookup db read-only for normal users. This will prevent them from modifying the contents, and will also result in error messages. Hopefully will these error messages point me in the right direction of the bug.
Problem is that the ldb, created when opening the mdb, inheritates the same security settings of the mdb. If we set the mdb to read only, the user gets an error-message stating it can not find the lookup db or that the lookup mdb is locked. This is because the user can not create or modify the ldb. On the other hand, if we set the security to create and modify for the mdb, the user still is able to change the data in our lookup db.
I have never worked with the security in access itself. and I want to try to avoid that. Is there a way of securing the data in our lookup db. So I'm able to figure out what really goes wrong.
I've been fiddling around with the Tools>>Security settings but I can't seem to find a way where only I can make changes to the database and the users can't just use the switchboard. If you are regular user you don't need password but if you are admin you do.
My database was working fine until I split the database and now I'm having issues with this function:
Code: Public Function OpenFirstAttachmentAsTempFile(ByRef rstCurrent As DAO.Recordset, ByVal strFieldName As String) As String Dim rstChild As DAO.Recordset2 Dim fldAttach As DAO.Field2 Dim strFilePath As String Dim strTempDir As String
[Code] ....
It's getting stuck on the "strFilePath = strTempDir & rstChild.Fields("FileName").Value" line. The debugger says that there is no reord. The strTempDir is correct. I am assuming that the issue has to with linking to the database.
I am experiencing a problem with the mousetrap sample after I secured my database.
When I save on my main form and I try to go to my subform I keep getting the "Please Save this Record! You can not advance to another record until you either 'Save' the changes made to this record or 'Undo' your changed."
I have saved but it is still preventing me from going to the my subform. I numbered the Save Required msgs so that I know which one I am getting and I am getting the one from:
Private Sub Form_BeforeUpdate(Cancel As Integer) On Error GoTo Err_Form_BeforeUpdate
Me.tbHidden.SetFocus
If Me.tbProperSave.Value = "No" Then Beep MsgBox "Please Save This Record!" & vbCrLf & vbLf & "You can not advance to another record until you either 'Save' the changes made to this record or 'Undo' your changes.7", vbExclamation, "Save Required" DoCmd.CancelEvent Exit Sub End If
Exit_Form_BeforeUpdate: Exit Sub
Err_Form_BeforeUpdate: If Err = 3020 Then 'Update or CancelUpdate without AddNew or Edit Exit Sub Else MsgBox Err.Number, Err.Description Resume Exit_Form_BeforeUpdate End If
End Sub
Above it is checking if tbProperSave.Value = "No" and in bSave you have Case vbYes: 'Save the changes Me.tbProperSave.Value = "Yes" DoCmd.RunCommand acCmdSaveRecord Me.tbProperSave.Value = "No"
So it's setting the value to no again?
I know it's not a permissions thing because I am admin and have full permissions on the forms.
We have a database that is split. Every user has their own front end (installed via a .bat file so that the users always have a local copy of the most recent version), linked to a shared back end on a server. This seems stable and functional for us so far.
However, because our users are geographically separated, I don't actually know how many folks are using the database. I know the folks who contact me, but everyone in our company could use it if they wanted to.
For requesting funding, guiding future development, etc., I need to get some metrics:
Total number of unique users Avg uses per day
Total number of simultaneous users (daily, weekly, and monthly maxes and mins)
What is the best way to get this info? Write user info and a timestamp to a table each time a front end is launched? Are there tools for monitoring this sort of information?
I have a split Database into Back-End and Front-End. I want to hide the Access Customize Option in my Front-End. I have tried to make the Database ACCDE but the option still appears to Customize the Access Database.
I also want to know why is it that when i make a Database ACCDE - some of the codes are not working properly???
Background Info: I developed our main department's Access 2003 split database which is on a server for 15+ Users. I've now been given Access 2007 for development -- Users still have 2003. There are also 2 other smaller databases that are not split (.mdb).
Problem: In the split database, I've saved the Application .mdb as 2003, relinked and made a new .mde. But the Users still cannot open the database. (I did this in a copy until I figure out the nuances with 2007.) The 2 other unsplit databases can be saved as 2003 version and Users can open OK.
I'm grateful for any suggestions on working with Access 2007. I've been trying to tackle the ribbon which is a whole other question.
I have a database which I've split and I've put both the frontend and the backend onto the network drive.
I'm pretty sure it's the case that the backend should be on the server and the copies of the frontend should be deployed to each of the computers that people are working with rather than each person working on the same frontend copy within the server. would this be right to say this?
At the moment there is two people working on the database and the third person cannot access the database because it's freezing and the 'access.lockfile.9' is showing on the third users computer for both the frontend and the backend.
Does anyone know how I can resolve this problem? is it a case of copying the frontend to each of the computers that the users are working with rather than them accessing the same frontend from the network drive.
Connect an existing Access project to a different SQL Server database and the instructions are so simple however when I get to On the file tab click SERVER to open the Data Link Properties Dialogue, there isn't a SERVER option to click on.
My SQL server was on my local machine because I use Goldmine PE 9.2. I moved the SQL server to a different machine, I can connect to it, I can use it with Goldmine, all is well from my local machine except when ever I use my .accdb file, since the SQL server has been moved, I have to login with each request by the access file. This is sometimes six and seven times per session, waiting, error message, logging in, waiting, error message, logging in until it has all it needs to produce my required lists. It's mind numbing and I can't for the life of me find where I can reconnect to the SQL database so I don't have to do this so many times per session.
In Access 2010 32bit running windows 7 64bit. How do I find the datalink properties to connect my .accdb to a different sql database?
Is it possible for me to give them access to part or all of the database so that they can run queries to target venue mailshots etc if so how would i do this?Secondly my concern is that the database is valuable and I want to protect myself from potential theft of info, ie what stops them taking the database and using it for there own purposes?
I have a client that is using a split database. I am working on an update to the program and need to transfer a table to the backend that has the correct structure and information included in it. My thoughts are to make a one time use program that transfers the table to the backend. I have seen DoCmd.TransferDatabase and DoCmd.CopyObject as possible ways to go.
I am currently working on an application where I am using MS access as my FE and working with linked tables to SQL server BE. I also have a few temp tables within Access that are not linked but needed.
1. What are my steps into making this into a SPLIT DB? I am assume the BE will have my linked tables from SQL and the FE will have my temp tables and forms. Is this correct? 2. Once I split it, then I can make an .ACCDE file for a Mulit User environment, is this correct?
