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.
Related
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.
(Table Relationships)
I'm developing a travel agency database, and I've got a table for contacts (people), a table for trips, and a junction table, people_has_trips. "Trip" refers to a table whose identity is mostly many-to-many relationships with various optional travel elements such as hotel, flight, etc. (I have doubts about this structure, but that's an issue for another question).
Anyway, I'm in the early phases of designing the form for Trips, which will almost entirely consist of subforms linking to junction tables. The problem that's given me the most difficulty so far is that of how to add a contact to a trip. I'm fairly new to access, and thus far I've been populating such tables using autofilling comboboxes, but the contacts table contains over 100,000 records, and as such some sort of search function would be prudent.
Here's what I have so far. This subform is based on the people_has_trips table, and currently is limited to showing existing records. I disabled all fields as not to allow the editing of People records, but I'm somewhat stumped as to how to handle adding more people. In my limited Access knowledge, the most logical solution to me seemed to be having a button to open a form that would allow the searching of People and perhaps the addition of new people.
Now, I have a fully realized form for entering new People (shown below), but it doesn't have any real search functionality besides Access's built-in filters. So my subform currently opens People and... does nothing else. Quite frankly, I have no idea where to go from here. Do I develop a second form for searching people, or do I build in search functionality to the primary People form, something I should probably do anyway? If so, How? And after doing either of those things, how do I then populate people_has_trips? The only answer I can think of involves the user clicking the button to open People, finding the person they want to add, and then manually entering the primary key into the subform, which surely isn't optimal.
The aforementioned People entry form
The solution, I would wager, is VBA commands. I've recently taken the time to learn some VBA, and I'm a bit more comfortable with it, but I just don't know where to begin with this problem. I'm confident that I can adapt and apply other people's VBA ideas and code, but I can't find a thread on this particular issue from which to do that! I'm guessing the reason I can't find any help for this issue is that it's so blatantly obvious that nobody has asked the question yet, or my Google skills are lacking. Either way, I'd be quite happy to facepalm in realization of the solution. Thanks any and all for their help!
You need to be focused on your core problem and as far as I understood, you want to search and add "users/contacts" to your "People on this trip" form.
Yes combo-boxes can eat up time loading 100k rows and it's not really search friendly.
In your "People in this trip" form you can:
have a text box => for search
have a combo-box => showing search result
[Search] [Add] [Clear] buttons
In theory,
search button performs a search on your TContacts table and assigns the results to the combobox. something like SELECT PersonId, FirstName, LastName From Prople WHERE firstName like #keyword OR lastNAme like #keyword ... other fields
User selects a specific result form the combo-box.
Add button then performs SQL operation adding selected user to your junction table and refresh your junction table.
something like: INSERT INTO people_has_trips (people_personId, trips_tripId) values (#selectedPersonId, #tripId); followed by requery
This is just a theory, you need to try out something and narrow it down to a specific problem. Otherwise your question might be marked as too broad.
I am currently in the planning phases of developing a multi-user shopping list application for mobile devices. In a nutshell, it will allow a registered user to create shopping list categories and then add individual items to one of these categories. The users' sets of categories and the items underneath will make up their "list." The user will be able to share their list other authorized users. All these users and the list creator will be able to edit/update these lists.
I'm not very familiar with database design although I feel relatively comfortable with mySQL and its syntax from limited use in past projects and web development. From the tutorials I've read, it is important to minimize redundant data, and in order to do so, and also leverage some of the power of relational database systems, I must use foreign keys and reference table(s).
This is what I've got so far, but now I'm stuck:
Essentially my main question is the "list" table done correctly? The way I am seeing this work is that as a user attempts to add an "item", we first to make sure some other user hasn't already created an "item" with the same name; this is to prevent duplicate item text from being stored in the database. If that item name already exists, just toss back the item_id to client program. The same process should occur when a user attempts to create a category. This idea came from my (very) basic understanding of trying to eliminate duplicate objects. If either of these objects don't exist, then they get created in their respective tables.
So now I would add the information to the actual list table. The user_id references which user owns the list, category_id points to a category in the category table and item_id points to an item in the item table. "checked" simply represents whether the item has been checked off the list, but not yet removed.
Is this a tenable design, or should I just start over from scratch? If so, can someone give me some clues as to a better design?
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.
I currently have an MS Access application that stores information about the employees who have responsibility for a certain task.
My form goes like this. You enter the task in a textbox. You pick the employee from a combo box which is bound to the staff table. And finally we save this information to the Task table. As simple as that I thought...
But here is the problem. No employee works forever in a company. A new/another employee maybe assigned the task which was previously carried out by an employee who is no longer working there. In the form once I update the new employee the old employee information is replaced and we wouldn't even know that that employee existed.
I came across the concept of adding effective dates to the employee which may be used to track the history of employees.
Now I would like to know how I would be able to preserve the data of the previous employee when I update the Task form with the information of the new employee.
What should I do?
Thank you for your assistance.
BR,
Paul
I have uploaded links to three forms that I am working on.
In the outside company officer form we don't have the date fields mentioned.
In our companies proposal form we might need to add additional officers but don't want to repeat the proposal information just the officer, division, alternate officer & division.
In the outside company detail form we might need to apply the same concept to the director of the company without applying to other institute information.
I was also researching on this topic where I found a document which explains the concept of effective dates. I need to know how to apply this and also without making a lot of changes to the application.
www.gsa.gov/graphics/staffoffices/DatedInformationandDateTracking.pdf
I hope this helps you understand my problem.
It would seem you are keeping very simple information, you want to know who is currently assigned to any given task. Add a "assignedDate" field to your table. Then you can change any reports or forms where you need to display the current assignee to a query whereby you group by "task" and select only the latest record.
Do not include the assignee as a field in the task table. You would need an additional table, say "TaskAssignees" comprised of TaskID, ContactID, entry date, assigned date, unassigned date. Now in reporting you can pull the correct assignee given any date or list a history of the assignees from start to finish.
I would say that you are making the issue too complicated.
Surely there's an administrative policy on what happens to tasks when an employee leaves -- their replacement takes them over or they are assigned to the departing employee's supervisor or a co-worker.
Thus, your application should encode that business practice. The form where you edit the employees should be set up so that when an employee leaves, their tasks are moved to the appropriate employee. This means you don't have to store effective dates and then write the complex SQL to filter by those dates. Instead, you'll use the same structure as you already have.
Now, of course, I'm not stupid -- I know that many companies SHOULD have such policies, but very often, these things fall through the cracks. When I'm in this position (as an outside contractor) I tell them their two options and price the two options. Implementing a policy for what happens with the assigned tasks when the employee leaves is cheap. Implementing an effective date is EXPENSIVE. So, if they want to save money, they'll come up with a policy that can be implemented in the database application.
If the solutions already suggested don't work for you then you could look at creating an audit table which effectively logs every change that is made to a record (This would have the advantage of allowing you to track ALL changes, even in areas of your system you have not yet developed).
Here are a couple of links that show how you could go about doing this:
a simple solution for tracking changes to access data
Allen Browne - creating an audit log.