I am fairly new to MS Access and looking for a solution regarding a form I am trying to build. The form should be used to show different user entries and to create or modify users.
The problem I am blocking is for a combo box and a many-to-many relationship.
I have several tables which combined provide me the information I use to build the form.
My first table Users provides me information about *first name, last name etc. *
A second table Servers includes the list of different country servers a user can have access to.
Since an user can have access to different servers/countries and a country/server can have different users I am confronted with a many-to-many relationship. Therefore I created a junction table which includes the userID as FK (from the User table) and the ID as FK (of the country/server from the Servers table).
What I am trying to achieve now but where I am blocking is:
to have a combobox which lists all available servers/countries
mark the entries which are linked to the user record which is shown
e.g.
Servers: Belgium, Germany, Netherlands, Sweden, UK
User: John Doe => access to Germany & UK
list/combobox should show all countries but select only the ones John doe has access to (when record John Doe is selected)
Is there any way to achieve this and what needs to be done ?
I am also open for any other solution if this cannot be done via a combobox.
Thanks for the help.
Related
want to create simple access db that will allow entry of customers that do business in multiple states. So be able to create company table with things like company name,email, state but be able to put in multiple states if that company works out of more then one. Say company a is out of Florida, company b is in new york, florida,texas, company c is arizona and florida. once all tables created would then want to be able to query all companies operating in a given state and get list of the companies. so if i queried companies operating in florida, i would get companies a, b and c back in this example. So how best to create the underlying tables and joins/relationships in access to make this work? any example access dbs i could download and use as template would help or a good explaination of how best to setup the needed tables (companies, states,etc) thanks for the help
You simply want to create that main table tblCustomers.
And then create a child table called tblAddress.
In the child table, you can thus enter the address/state/phone number of the company address(s) you have. So you might have one, or 5 such different addresses.
To edit this setup, you thus create a main form with company info etc. You then build a sub form that allows edit of the address.
Then with main form in design mode, simply drop in the form from the nave pane. If you setup the revelations between the tables correctly before doing this, then Access will automatic link up the address for the given company.
So you don’t need a multiple states table, but simply a table that represents the whole address. You as noted might want to include the email, phone number. Thus you can easy enter a company, and then enter address (with state) along with email or phone number for as many locations as you please.
So far, this relation as outlined only requires two tables. The main table, and the table of addresses.
I have an access database with two tables, one for users and the other for user permissions.
The users table has a list of user names with a unique ID:
ID | Name
1 | Joe Bloggs
2 | Steve Smith
3 | A Another
and the permissions table has a list of user IDs and the zones theyre allowed to access:
ID | Zone1 | Zone 2
1 | X |
2 | | X
3 | X | X
I have created a form for updating the user's permissions based on the permissions table which all works fine stepping forward and back manually, and on this form I have a combo box that lists all the users from the first table.
My question is, how do I make this navigate to the record in the permissions table? I know i need to put some code in the "after update" field for the combo box, and managed to get it to work when the combo box was displaying the User.ID field but not User.Name. I have also set a relationship between the two user ID fields but this hasnt worked either.
In Summary, I want to select "A Another" from the username drop down box, this has an ID of 3 in the users table, and then navigate to record ID 3 from the permissions table.
Thanks in advance
First off, your table structure is not well normalized or structured. If you have multiple zones that users may have permissions for, it's inefficient to store each zone-permission as a column. It's hard to get information about zones a user may have access to (zone metadata), and adding a new column for each additional zone can greatly increase your database size and make queries troublesome.
A better approach would be to have 3 tables:
Users(ID, Name) <-- this would be the same as what you have now.
Zones(zone_id, additional_zone_attributes)
user_zone_permissions(user_id, zone_id, additional_permission_attributes)
With this structure, you could still use #LeeMac's answer of using a sub-form: The parent form would list user details, and the sub-form would list zone permissions:
With this structure, it would also be trivial to add additional privilege attributes (maybe down the line you want to add effective dates of the privilege).
Just make sure to set your primary keys and foreign keys (using the Relationships) screen appropriately:
Now, after all that is said, if you can't refactor your structure, you don't really need to use sub-forms at all. Since your users and permissions table seem to have a one-to-one relationship, you can store everything on one form (either putting everything in one table, or tying the form to a query that combines the data). But, like I said, you'll be better off changing your structure if you can.
Insert a subform in your form with the Master Field set to the ID in your Users table, and the Child Field set to the ID in your Permissions Table.
This way, no event handlers are required and the displayed records will be changed automatically.
I am trying to develop a new website for event management system.
I want everyone to sign up as a simple user only and then if they chose to run event user can then create an Organisation and create events.
Every club will have lots of staff members who should then be able to log in and make changes into the event. Like accounting,event set up and entries, Refunds etc.
So I have created few roles like following
clubOwner :- All permission
eventManager :- Tier 1
treasurer :- Tier 2
Now how should I structure staff roles and permission table so that if in future creator of the club leaves that organisation he/she can easily nominate someone else clubOwner.
It is also the case that one eventManager handles events for different clubs or they can also run events under own Organisation name.
So far I have come up with following structure
clubs
=========
id | clubName | clubOwner
club_staff
id | clubId | accountId | roleId
club_roles
id | name
club_role_permission
id | roleId | permissionId
club_role_permission_details
id| name |
I am not sure if this will solve both of my problem of clubOwner easily nominating other user and same user with different roles in different clubs.
Any suggestion will be appreciated.
Thank you
Though this topic is subjective to many developers, I believe you are in the right track.
Permissions - normally corresponds to smallest unit of actions like View Club Staff, Add Club Staff, Remove Club Staff and so on. Normal club staff can view other staff within their club, but cannot add or remove club members.
Roles - are group of Permissions that are related to each other. ClubManagerRole for example must have all the permissions related to managing the club, while ClubStaffRole can only view members for example.
Users - are your users, that's all.
UserRoles - a junction table which has many-to-many relationship between Users and Roles. In other words, a user can have many roles, and a certain role can be assigned to many users. Just like how there are many Club Managers but maybe some of them can also be Other Managers.
Clubs - are your clubs.
ClubUsers (or staff) - are the users of a club. If a certain user is allowed to be a staff of one club only, one-to-many will be a fit choice. Otherwise, you can go with a junction table again for many-to-many relationship which will allow for users being assigned to many clubs.
The nomenclatures again, are also subjective. You can search for Database practices/normalization to get a basic a idea on how one can come up with a good schema.
This is a bit embarrassing but it's been a while.
When working with relational databases and linking to separate tables by primary:foreign keys, in 1-∞, such that, in a particular table, the table's foreign relationship returns an integer ID... how do you go about making this relationship intelligible to users?
For example:
You have a company table
CID
CompanyName
CompanyLocation
CompanyBusinessType
etc (not actual column names)
and an employee table
EID
firstName
surName
DOB
email
company
Employee company is related to CID. But some user putting in information about an employee would have to know the ID code for the particular company due to the nature of the relationship. You can run a query to return 'CompanyName's along with their associated 'CID's which can then be searched, but this cipher is hardly an ideal solution. I just cannot remember the theory of how one approaches this, even though I'm certain I've done it before. I need to implement it in both Microsoft Access 2010 and Microsoft SSMS (separate databases fwiw); but the execution should be relatively straightforward as soon as I remember how it's done!
Create a combo box with 2 columns. One column as the company name and the other as the company ID. You can set the width of the company ID to 0 if you don't want the user to see it.
This can be done with the Property Sheet on MS-Access Forms
Set the Row Source of the combo box to:
SELECT CompanyName, CompanyID FROM Company;
Set the Control Source of the combo box to:Employee.CompanyID
Also make sure the Row Source Type is set to Table/Query
If you need a many to many relationship (many employees belong to many companies) then you will need another table CompanyEmployees, something like this: -
If an employee only belongs to one company then this structure will do fine: -
In either case you will need to display the user with some form of drop down list when adding / editing a user to associate the users with one or more companies.
Here is the situation:
I have a "user" , which have many attributes. For example, "name", "email", "password", "phone".
There are some attributes that are open for public, for example, "name", "email".
These information is open for evenbody who visit the site.
But some, only for trust body in the system, for example "phone".
These information is open for the people that the user trust.... (Assume the user have a trust list that can accept other user to the trust list.)
And the private one "password".
This information is only for the user only, other people can't get access to it.
User can change different security level based on their need, for example, the user want to change the "email" for only trusted body, they can do so. It is also allow the user change their "phone" to public.
I use three number to represent three level of right. The first one with 3, second is 2, and the private is 1. So, I design the database in this way:
User
id(PK)
nameId(FK)
emailId(FK)
passwordId(FK)
phoneId(FK)
Name:
id(PK)
name(String)
securityLevel(int)
Email:
id(PK)
email(String)
securityLevel(int)
Phone:
id(PK)
phone(int)
securityLevel(int)
Password:
id(PK)
password(String)
securityLevel(int) //It must be 1
The question is, I can do it but my database will have many table, is there any simple way to do it? Moreover, is there any books about these kind of database design is recommended? thank you.
You don't need different tables for this, because each relation is a 1-1 relation.
Should a user have, say, multiple e-mail adresses, then you indeed should put the email and securitylevels in different tables. But because in this case, each user has exactly 1 email, 1 name, 1 phone, 1 password - just one table with 1 row per user should do.
If I understand this correctly, you could simply put all this information in two tables (user and friends) because as far as I know, it is a lot more efficient to get larger chunks of data with few queries, than smaller chunks of data with many queries. You would have something like this:
Users:
id
name
name_perm // 1, 2 or 3
email
email_perm // 1, 2 or 3
phone
phone_perm // 1, 2 or 3
password // Doesn't need permissions, always 1
Friends:
user_id
friend_id
When a user visits another user's page, first you check the permission level for each field. If level 2 is found, you would then query the friends table and check if current user ID is a friend of the user whose page is being viewed. If found, user is trusted and level 2 security info can be displayed. As for level 1 security, it's really simple - only display this info if both IDs match.
Hope this helps.
Whether or not the private data is segregated into a separate table does not solve the issue of how to prevent unauthorized access. The MySQL 5.1 manual section 5.4.5 discusses request verification/privileges, but if your database is hidden behind a web application with no direct access to your tables, then standard web server security alone might be sufficient. You should probably mention the entire os/server/db/language bundle you're using (LAMP, SAMP, whatever) so someone can suggest the best security scheme for your configuration.