I use access to store concert registration information at the non-profit I currently work at. I have it set up so that I dump all of the patron contact information into one table, and all of the concert registration information into another. when we change our concert season, I simply copy/paste the "2012-13 concert registration table" and rename it the "2013-14" concert registration table".
the concert registration table serves as my "hub" for all my other information. I have about a half-dozen summary queries that show information for specific concerts, who I still need to collect payment for etc. as well as many Word mail merges associated with each document. This setup works great, except that every season I need to go in and re-link all of the queries and word docs to the new registration table
I will be leaving my job at the end of next month, and I would like to make the database more user-friendly, especially since I am fairly certain that my replacement will have zero familiarity with access. my questions are:
1) Is there a more elegant, easy way to transition from season to season other than to create a new registration table and subsequent queries from year-to-year?
2) How can I idiot-proof this database for the new person when I'm gone? I'm scared that if I create an extensive "how-to" guide, it simply won't be read and the person will be forced to reinvent the wheel. I'm toying with creating a switchboard, but I'm scared that this will make the database seem more unapproachable.
Thank you for your insight, happy to clarify if there are any questions!
Just make 1 table. Call it "registration table" and add a new field called Season. Your queries will be include a filter for that field. Then you won't need to relink your queries, copy tables, etc.
For an example, say you have a query to pull all the information from that table for a particular season. It might look something like:
Select * from RegistrationTable where Season=[What Season];
When run, the query will prompt the user for the season and pull only that data.
Also, I do recommend the "how-to" guide. There's probably a lot of manual manipulation of the database that you do and don't even think about. And if nothing else, you can always say you gave them documentation and thus provided for your successor.
Related
I am attempting to recreate in MS Access a personal productivity database that I had in Notion (created based on this https://www.youtube.com/watch?v=32dLXdB4ozs). Basically I have a bunch of things (Projects, Meetings, People, Partners (which are orgs), tasks, etc.) and relationships between then. Each project has partners. Each meeting covers certain projects. People work on particular projects and for particular partner organizations, etc. Lots of these relationships are many-to-many.
I've set up most of the back-end stuff: I have a table for each "thing". I also have tables for each many-to-many relationship. So for example I have a People by Partners table to show which people work for which partners, a Projects by People table to show which people work on which projects. A Meetings by Projects table for which meetings are about which project...etc. etc. i have made each field in this a linked relationship to the other two forms. So for example, the projects by people table has a project field linked to the project page and a people field linked to the people table. I've set all of these relationships to have data integrity and to do cascading updates.
Now I'm creating the more interface-like part, which will be used both for viewing and entering data. So I'm starting with a project form. In the project form, I'm putting a sub-form that will list the partners on that project. I created that form based on this video (https://www.youtube.com/watch?v=N46mgIqLXbA&t=0s) which you probably can't see, but the basic idea is that it's a combo box with the record pulled from the partner table and then the update linked to the partner by project table. I have set this to pick from a list since there are a limited number of partners.
Ok, now here's where I'm running into a problem:
I want to set this so that if I enter a partner name not already on the partner list, it gives me the option to add it as new. I've set it up using this code: http://msaccessgurus.com/VBA/Code/Combo_NotInList.htm . T
he code works fine (* sort of, see next para) if I do it directly to update one of the original tables (e.g. Partners), but I need it to update the Partners by Projects table.. I need it to put in the new Partner name, link it to the currently-viewed project, and then from there update the Partners table (which I thought would happen with the cascading updates).
Instead if I enter info not on the list, it asks me if I want to add it and then when I say yes, nothing happens. It doesn't add. In the form field, it shows me the dropdown list of existing partners to pick from. It tells me there's a syntax error and the error seems to be somewhere in the error proc.
How do I get this set up so I can enter the names of new partners and it will appear correctly as added wherever it should appear? Obviously the partners/projects is just one case where I will need to do this, so i need to figure this out or the whole system can't work!
Thank you for any help. Please note: I am not a professional (or even particularly skilled) programmer. My job is something else entirely and I am a muddling amateur with a basic understanding of programming and database concepts and some minor experience with other programming languages, but absolutely nothing with vb.
I am struggling with an issue in designing my Access database.
I am a caregiver, and part of my job is taking clients out into the community. I am attempting to build a catalog of outings to help the employees at our company come up with and store ideas for these. I want to store information for each of up to 5 types of events that clients can do at a location. That information includes the event type, when it runs and doesn't, and how much it'll cost, all of which would be user-selectable. (Separately in the same table, I want to include contact information and information that helps the user search for event locations, such as the ZIP code.) I have attempted to normalize the database by spreading event information across fields in the main table, linked to lookup tables. I am aware that Access has a limit of 32 relationships per table.
To help staff find event types, I am trying to set up a method for categorizing them. That requires setting up nested lookup tables, as shown in the first picture.
If I understand correctly, the additional "copies" of those lookup tables are aliases. When I save the setup for the relationships between those aliased lookup tables, close the Relationships window, and open it again, I find Access has changed them, as shown in the second picture. This happens whether I delete the lookup table information for each field in Datasheet View. I don't understand why it does this or how to fix it.
To answer your question:
In the object browser I see that you have only one table: t_OutingType. Therefore, the "tables" t_OutingType_2, t_OutingType_3 are just aliases; "pointers" to the same table (like a shortcut to a document). When you save the relationships and close the window, the relationship information is written to the metadata of the database. When you re-open the Relationships window Access re-builds the relationship diagram from the metadata, and it does not include the redundant aliases.
Additional advice:
Whenever you find yourself duplicating columns in a table, e.g., Event_1, Event_2, ... a little voice in your head should start shouting "Are you sure that's a good idea?" Imagine if you want to search the database for events that fall on a certain date. With the table layout described above you would need to ...
SELECT ... WHERE EventDate_1 = [theDate] OR EventDate_2 = [theDate] OR EventDate_3 = [theDate] ...
It's almost always better to split the Event information into a separate child table and maintain an association table between the child table and its parent.
I am planning on creating a database to track user's time in/time out M-F. Every week should begin on monday and run through sunday.
I have a table filled with my entire user population, so I know which users I need to create entries for and where they belong to. I have proposed so far, a table consisting of the following fields to track the entries (along with example data to fill the fields):
Field Name in table (Example of possible data)
---------------------
Employee (John Smith) 'String
Unit (Quality Assurance) 'String
WeekOf (9/9/13) 'date
InMonday (6:30) 'string, validate either a time in/out or N/A if holiday/vacation
OutMonday (3:15) '^^
HoursWorkedMonday (8.00) 'total hours worked
VacationMonday (0.00) 'if N/A for time, should have hours here
OvertimeMonday (0.00) 'any additional work hours should go here
For this instance, I would have to create In/Out for each day of the week (and perhaps track the date that each day is for). Is this extraneous or is there a seemingly better organization to tracking weekly time measurements? Should I use one table with a unit indicator or multiple tables for each unit?
Usually it's one table with a Date field, an In field and an Out field. That's pretty much standard timesheet data. Take a look at how this guy has it set up.
Make sure you're using an Employee ID in the timesheet, and then you would have a corresponding Employee table with all relevant info (ID, Name, Address, whatever else you store on him/her).
While this project is technically feasible, I have to question the value of making it yourself in Access.
The main issue is with security:
As a desktop program, this can be very easy to hack without precautions. Keep in mind that with Access, the user interface and the designer interface are by default the same thing.
If this is going to be a simple, straightforward db, a motivated user just needs to open the navigation panel and they can add/edit/delete all the timesheets.
If you hide the navigation panel, the user can just do a quick google search and learn to hit F11 (or find it by accident, either way)
You can try regularly (daily? hourly?) transferring the data from the publicly accessible back-end to an archive db that is not accessible to the general users. This can work, but still gives them a window to edit records. And if you don't do the transfer right, they can still add old records.
As a webform on a SharePoint, this can be fairly secure. I'd recommend this if you have Sharepoint.
You should also consider your development time. This is a very common business task across many industries, from restaurants to factories to schools. As such, there's a huge number of cheap web-based options already out there that you can start using today. I'll even assume some of these include summary reviews breaking out numbers by departments as well.
I've never researched these myself, but a quick google search found this interesting page: http://en.wikipedia.org/wiki/Comparison_of_time_tracking_software
I'm new to the forum, and I've tried searching for an answer but I can't find specifically what I need. Here is the deal. For a collage project I have to make a car rental web application. I've come up with an idea what should it do and for that I've created my ER model. But I'm not sure if it's good. The thing is not to do very complicated application, but to cover one RAD tool. I've ended up with Iron Speed. Here is the idea of the application.
Customer can come to website of car rental, and make a reservation, beside other things he can choose start date, end date, and car.
Employee can edit, and see all the reservations, and also make a reservation if customer comes personally to "office". He can also add new cars to database (type of car + model etc.) and make a bill for each reservation.
Administrator can add new employe and everything else (but that's his main thing let's say).
Table USERS has all the information about employees and administrator, and roles has roles in it, and they need to have a bridge table (this is needed because of the RAD tool to make user roles permissions).
Information about customers won't be needed separately (this can be a bad thing but let's leave it that way), and we have their information in REZERVATION table.
NOTE - I know it would be logical to connect employee with reservation (one to many) but that gives me the problem that customer needs to select employee when making reservations, same with car adding, it's stupid to select employee to add car... I mean its logical that someone needs to put car into database. For bill it is logical so I know who made it.
Car type and car are connected with reservation that way so I can make filtering type - > model later in drop down menus.
Link to jpeg: http://dl.dropbox.com/u/50541281/SnapShot_121124_220841.jpg
Link to mysql workbench file: http://dl.dropbox.com/u/50541281/car%20rental.mwb
I would really appreciate it if someone who knows can modify it as needed, or put some bridge tables if needed. Or just type notes here so that I can adjust my schema myself.
Just to add, this is only let's say need to see version of ER model since I've just translated it from my language to English, so all attributes, types, etc are not there.
In this situation you may be best using a join during the sql statement to get the information. Assuming the employee doesn't have anything to do with this account until later in the process (after booking the car) you should leave it to the other interface. When the cars are booked an employee should log in and check, if they process the order then add the EmployeeID to the table then. Leave it without relationship, it seems messy but it is a quick solution.
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)