I have a table named tbl_Subjects_Taken which lists all the subjects taken by the student. It is consists of only two columns, Stud_ID and Subj_ID.
Going out to the front-end, I have a form that lets the user edit the information about the student itself and the subjects taken by that student. Updating tbl_Students (the student's information) is not a problem as a single UPDATE statement can do the work. But what about the other table?
Once the user edited the form and pressed the save button, here is what I do:
Delete all the subjects taken by that student in tbl_Subjects_Taken.
Add all the subjects located in the form (in my program).
Is this really the right way of updating a table in the "many side"?
I use SQL server.
Deleting and re-adding is one way to do it.
But I would try to do everything on the server (e.g. use a stored procedure). I would pass in the list of subject IDs to the SP. Inside the SP, I would do the following:
Delete any subjects from tbl_Subjects_Taken for that user that were not in the list that I passed in
Add any subjects that weren't in the tbl_Subjects_Taken table that were in the list I passed in.
You didn't mention your DB, but there are different ways to go about this depending on what DB you are using. In Oracle and ODP.Net, for example, you can use a PL/SQL Associative array to pass in the IDs to your PL/SQL function/SP.
But ideally, you want to make one server round trip, and you want to do as few deletes and inserts as possible. Those two steps should result in good efficiency.
Related
I have a contact database, created on SQL server. An example of its many to many relationships is below:
1- Contact table (ContactID, Fname, Lname, ...)
2-Contact_Skill table (ContactID, SkillID, Score)
3-Skill table (SkillID, Skill_name, Skill_type)
For easier interaction, I linked this databse with MS access file (which will be the interface, used by users). Users mainly use it for insertion, and I have somewhere else a SQL report server to retrieve some data and do some reports.
My issue now is that, I'm trying to find an easier way (without programming) to insert data in the intermediate table (Contact_Skill), other than getting the IDs manually. A thing like a drop down menu, that enables the user to choose the skill and it turns into its ID. Any easier way would be so welcomed as well. Thanks
Ok, you likely don't need code, or at the very least VERY little code, and you certainly don't have to write code to insert the records.
So, I would create the form (bound directly to the linked contact table.
So, you can use ctrl-f, or whatever to search, find, jump to your record you want to edit. (so built in search features will suffice for now).
In that form, you will drop in a sub form. (a continues form - multiple items would work nice here.
So, in that form you have this:
In this example, I have
customers
Invoices
Invoice details
So, really, I have near example the same kind of setup. One master table (customers)
Then a child table of invoices.
And then for each invoice, we have details of the invoice.
So, your main form will have that sub form dropped in that shows the contact skills.
In my case, I have this:
So, for this, you not really written any code.
Now, do note that for each invoice (or your case of contact skills).
Note how I have a edit button in that continues form.
This allows our "drill" down.
The code behind this button is:
if me.Dirty = true, then me.Dirty = False
docmd.OpenForm "frmInvoice",,,"ID = " & me!id
So, clicking on edit will launch a new "main" form based on invoice (or in your case skills) the ONE record.
Now for that skills record, it not clear if you have another drill down (child table), but lets assume you do!
so, In that form, you simply drop in another sub form (again continues items), and you thus are now free to add more skills to that one contact skill.
In my case, it is invoice details, so we have this:
The above screens are rather crude (they are test scenes), but it shows a design in which you dealing with 3 typical related tables.
So the whole system works with about 6 lines of code. Just keep in mind that when you drop in a sub form to relate child items? Access will setup the foreign key value that belongs to the parent table that has the one "main" record, and that sub-form of child records. All that is required is that the link master/child setting is setup correct. Once done, then Access will manage and set the correct values used to relate the tables to each other, and you don't have to write any SQL or even any code for that matter. (you are free to add a sub form record, and then hit Edit button for further details to edit, or as noted add more child records to that form you just launched.
So related tables, and adding of child records is VERY automatic in Access, and you don't write code to add the records - access will do all this work for you if you follow the above design pattern. About the only code you ever had to add is the the "edit" button to launch the next form in the sequence.
I have been tasked with create a tracker for company work flow.
I have 10 tables with data in them. There are attributes all the tables have in common. I made a table with those attributes, giving those records a unique ID that could join them to the unique attribute records of the original tables. I am also linking a personnel table to the original tables. All of these tables exist on my SQL Server back end. I Have made a query in Access that displays all the information I was given. I'm going to use the forms in access as a front end to display, edit, and add records.
The issue I am encountering is that I can not write to a query that has externally linked tables. I have spent a lot of time normalizing this data and I know I can get around it by making tables with redundant attributes in SQL and not writing to the query, but rather write to the linked tables instead. Just wondering if there is a way around this.
Thanks
In general, even without linked tables, such queries are NOT updatable.
The general approach when working with multiple tables is to use sub forms for the child tables. That way, each form is only bound to one table. (You are free even to bind such forms directly to the linked table).
Thus, you might say have a customer table and then a table of invoices. So your main form will display the one customer and is bound to that one table.
In the sub form, you can then display all of the invoices.
So to combine multiple tables into a form or screen that allows users to update the data, or add more data, you don’t build some query that joins all the data together, but simply combine several forms into one form. But each of those separate forms will display data from the given related child table.
Here is a typical invoice form thus built in Access:
The top part is the “main” form of an invoice. It is bound to the customer table – one record. Then the multiple lines of detail is the invoice details table. So the form does NOT use queries, but each part of the form and sub forms are bound to the given related tables. You are binding each form directly to the linked table (or tables if you need to show related data like above).
This approach allows you to cobble together a set of forms that edit related tables, but each form is bound directly to the linked table.
So the fact of linked tables or not is moot – such queries are not used to edit data and such queries from link or non-linked tables are NOT updatable.
So your form + sub forms will follow the pattern of related tables that you need to work together as one whole view and means to edit data. You don’t need nor want to use a query to fill these forms.
You most certainly will provide some kind of “search” form, or some means to pull up say one customer invoice, and that invoice along with its sub forms will display the related data, and also allow editing of that data.
I need to find a way to match records between two tables. The problem is a single identifier that would make the match very simple isn’t available so I need to find a way to make that match based on some other available information in the records.
In an elementary school all registered/existing students have a Student ID. It is unique and makes a perfect primary key. However, any new students entering the school for the coming year do not get a Student ID until they are officially registered.
Before the next school year starts the school invites the new incoming students to be part of a pre-registration assessment program to help determine their current level and needs for the coming school year. It is at this point that as much data about each prospective student is gathered. This information is stored in a separate table from the main student information, mostly because there is no official Student ID. The idea is to merge the pre-registration students and their data into the main student information table(s) once they have an official Student ID assigned to them.
My thinking was to assign these new students a temporary ID just to have a unique identifier for them in case there are name duplications.
My question is how can I match up the temporary ID’s with the real ID’s once the student is assigned one?
Some information that will be gathered in the pre-registration process will include Last Name, First Name, Middle Name, Grade, with Birthday being another possibility (but isn’t included at this time).
Maybe I’m going about this in the wrong way so any suggestions on offer would be greatly appreciated.
It sounds like you are exporting information from the main Student Information System, running additional processing in Microsoft Access, then ultimately merging it back into the main system. This being the case, you will have to work with the limitations in the export and merge features, and building your matching logic around what is available there.
Plan A: Ideally your Excel export would include some type of primary record identifier from the main system, independent of the Student ID that gets assigned later. (It very likely uses a unique ID internally, even if that is not included in the export file.) You would then use this to match to your records in Microsoft Access.
Plan B: If the primary system does not export a unique identifier, then you will need to come up with your best combination of data to uniquely identify the student. How you do this will depend on how many students you are dealing with, and whether the matched data changes in either system. Full name and birthdate is a fairly common way to do this, if that data is complete in the originating system.
With the unique identifier established, I would use two queries in Access. The first would be an update query to assign the Student ID to your Access system as soon as it becomes available in the main system. (Search for matching students that have a Student ID in Excel, but not yet in Access.)
The second query would be an append query to add the new students from the main system into Access. (Where the student in Excel does not match any existing student in Microsoft Access.)
Taking this approach, you would pull the Excel export regularly from the main system and run the above queries to keep your Access system updated. Then when you are ready to merge information back into the main system, you could filter on students in Access that have a Student ID assigned. The actual update of data in the main system might be done through an update query, or perhaps an export from Access that includes the Student ID. (Depending on how your main system merges the incoming data.)
The way I would approach this is to merge both tables into a single table of students. This table would have an AutoNumber ID column that refers to the student or prospective student. Then you would have another column in this table for the StudentID which would be assigned at a later point.
Your forms and reports can then filter the data based on the StudentID field to show you either current or prospective students.
Taking this approach means your student data gets entered into one place, and you don't have to worry about trying to repeat information or merge it later. Since a single record represents a single individual, it makes logical sense to me to use a single table.
For my internship I am making a database in Microsoft Access about employee's accidents at work. There is one table and one query in the database. For the form I want it to have one employee and all the previous and future dates of all the accidents they have had and the comments to show if they are repeating them. If this is possible how can it happen?
You'll need at least two tables: one table for the employee information (their name, employee number, and stuff like that) and another table for the accidents (employee number of the person who had the accident, when it happened, what happened, etc.). Then you could use a Form with an imbedded subform to display the information.
Microsoft has provided detailed information on how to use a subform here:
Create a form that contains a subform
i have two tables
student(studentid, name, class)
Course (courseID, CourseName, CreditHours)
these tables have many to many relation ship so i created a third table
student_course(studentID,CourseID)
Now i have designed the forms in ms access through which user enters data in student and course tables
But i want to design a from through which user can assign courses to students which means user
have to enter data in student_course table.
but i want to design a form though which users can see and enter the student name and course name insted of ID's at backend ID should store in student_course table,
Can anyone help me in this matter.
You can use a combo box .. try to insert a combo box on the form using the wizard and it should walk you through the steps in showing the course name in the front end and saving the course id in the back end database ...