I am new to Microsoft Access and I am trying to build a Case Tracking system for our Employee Relations folks. I have a table for Employees and a table for Cases. They are linked by Employee ID. I also have a form to incorporates fields from both tables so they can fill out when a case comes in. How do I save the data on the form into a master case history table? I want to capture the employee data as it was when the case was added since departments, managers and other fields are dynamic for the Employee. My form includes:
Employee Table
Employee ID,
Company,
Job Family Group,
Cases Table
Case Number,
Case Date,
Case Type,
I know I can obviously write a query to join them, but it will show me the employee facts as they are as of the last data refresh. Any help you can provide would be greatly appreciated! Thank you again.
Actually, the way you approach this?
Well, you have a main form - employees.
Then, you have (make) a sub form of cases.
Now, that sub form can be a grid like display - perhaps you select (click) on a row to show + edit more details, or perhaps just a sub form as a grid (continues form) will suffice.
In other words, you don't make the form update both tables at once, but in fact use a main form, and a sub form.
Say, I have a table of Hotels. And I need/want to display hotel information, and THEN ALSO display people booked into that hotel?
so, I create a form based on table People. That table People of course has a column that relates back to the hotel they are booked to.
So, you get this:
So, each form STILL ALMOST ALWAYS will be based on ONE table. Don't try and make some multi-table join for the forms data source.
So, in your example?
you build a main form - employees - it can show all the information (and let you edit/add etc.) to that form.
For each case, from the case table?
Well, go off and build a 100% separate form for display of "case(s)".
Then save that form. Now, open up your employee form, and in design mode, simple drag + drop in the cases form into that form.
So, you don't actually base the form and its table on more then one table, but you combine multiple forms EACH based on their one respective table.
But, as above shows, the end result is a main form + sub form, and that gets you the relational database setup, and allows you to do this without having to write code.
Related
With my limited knowledge of Access, I have been struggling to figure this one out.
I have 4 tables. tblJobDetails, tblDrawings, tblDrawingFixtureType and tblFixtureType. They are related to each other in that order.
What I have been trying to do is a query based from tblFixtureType. I want my users to have a datasheet where they can input all the fixture types for the given job, but keep them under that particular JobID. I have not had much luck in that department. All queries I have made either show every single type entered in the DB, or nothing.
The JobID is the PK for tblJobDetails and is a FK in tblDrawings. tblDrawingFixtureType is intermediate/junction table that is meant to hold quantities, but has DrawingID and TypeID as its FK's.
So how would I correctly build a query for my users to input all fixture types (designations), but keep them assigned/filtered under that particular JobID?
I am sure more info will probably be needed, so please ask.
You don't build a query to solve this problem. What you do is build a form based on each separate table.
In Access you model the parent to child relationships by using form + sub-form combos.
So, you might have a form that say lists out job (continues form).
You click on a row, and then launch a form with a nice display of the job details, and then in the sub form, you allow entry of tblDrawings.
The sub form will hook up the FK. And to edit/select the tblDrawingFixtureType, that drives a combo box in that sub form to select the fixture type, and it will save the PK of FixtureType in the one column.
All and any of each form (or even the sub form) is to be based on ONE table, and NOT a query. You don't edit data in tables, you build a form based on the table. If there is child records to add to that one record, then you build a sub form (and again, that sub form is based on ONE table).
Not only does this mean you don't have to create any queries, but you also don't have to write any code since when using a form + sub form, you get editing of related data that way.
I am constructing a MySQL Database with the end goal of creating a GUI CRUD frontend in Microsoft Access. In the attached picture is the layout for the contacts section of this database. [Current table relationships]
Ideally, all of the tables in this screenshot (barring payments) would be populated in one Access form, but I'm having trouble working out a way to make this happen. The most obvious answer (with my limited SQL knowledge) is to create a massive view connecting all of these tables, and then have the Access form call a stored procedure (either one massive SP, or one for each field? Not clear on this) to C/R/U/D the view.
I tested out creating a view with a few tables (one many-to-many relationship and one one-to-many) below:
CREATE
ALGORITHM = UNDEFINED
DEFINER = lauren3#%
SQL SECURITY DEFINER
VIEW peopleformview AS
SELECT
p.PersonID AS personid,
p.Title AS title,
p.FirstName AS firstname,
p.LastName AS lastname,
p.Role AS role,
p.DOB AS dob,
p.PassportNum AS passportnum,
p.Alumni AS alumni,
p.Degree AS degree,
p.Nickname AS nickname,
p.Email AS email,
p.PermissiontoEmail AS permissiontoemail,
ar.agent AS agent,
a.AddressID AS AddressID,
a.Address1 AS Address1,
a.Address2 AS Address2,
a.City AS City,
a.State_Province AS State_Province,
a.PostCode AS PostCode,
a.Country AS Country
FROM
(((people p
LEFT JOIN agentref ar ON ((p.agentref_agentid = ar.agentid)))
LEFT JOIN people_has_addresses pha ON ((pha.people_PersonID = p.PersonID)))
LEFT JOIN addresses a ON ((pha.addresses_AddressID = a.AddressID)))
Am I on the right track here? It seems that such a view would get unweidly quickly.
Be it the desktop, the web or just about any platform?
You model and display and edit relational data by cobbling together parts that are based on the relationships.
But, you actually base each part directly on a single table. You don’t create a view server side to join all that data together. And you don't use SQL either.
If you have one customer, and 30 invoices, then if you join the tables, then the customer will appear 30 times. You can’t possible edit such a mess as one data row.
So this would be the related tables:
So, in the case of access, you would build a form that edits the main customer. Such a form lets you edit one customer at a time. Build that one form – get it working all nice.
Again, above is based on one linked table.
Now, to display the invoices for the one customer? Ok, now build a new form (multiple items form). And you base this form on the invoices table.
Once you build the two forms? Well, open up your main customer form in design mode, and now simply drag + drop in the invoices form from the nave pane.
So, you wind up with a screen like this:
You can see the main form has things like customer name, address etc.
And the other form (a sub form) shows the list of invoices you have for this one customer.
The beauty of Access is it will connect up the main form, and the sub form for you, and do so without code. So, each main customer record you navigate to will now show the child related records in that sub form. You do this by setting the link master and child settings in the sub form control:
Now, of course each invoice will have a “main” invoice part. (Date, customer, maybe billing address). And for each invoice, you will have a child table of invoice details. (Quantity, item, price amount etc. for each thing in that one invoice). So once again, the above simple concept is repeated for this invoice form, and the child form of “invoice details”.
So, in above when I click on an invoice, we simply open up a main invoice form to the ONE invoice record, and the child invoice details is again displayed as a sub form. Like this:
So, be this desktop development, or even web development?
You create a user interface based on dropping parts into a form that are each based on a single table.
So each part that displays records as a general rule will be based on a SINGLE table. You thus as a result for such data editing will NEVER use a view or data joined together for editing.
And with Access you not use any sql either.
Each bit and part you used to edit data will be directly based on ONE single linked table in access and not some view.
As a result, you don’t need views, and you don’t even need sql for each part you build.
The ability to edit relational data will thus be based on how you cobble together each bit and part, but each of those parts are NOT going to be based on some sql query, and in fact not based on a view either. Each of the parts you use will be based directly on a linked table, and a single table at that.
Each part you use here ONLY ever edits ONE record at time. Read that last sentence 10 times to ensure you grasp this simple rule.
So, you can certainly get creative. So, here is an example form that shows 3 tables all at the same time. IN this example, we have an event, a then people and their donation for the event. And we need to split out the donation into different accounts. Someone might give $50, but 10 is for funerals, and the other $40 might be for the school.
The top part is the donation event (one record). ON the left side is a continues form that shows the people that donated to the event, and their amount. And on the right side we show the accounts for a single donation we selected on the left side. Each donation can be split out into multiple accounts.
This is a common and “classic” accounting type screen in which you enter a given amount, but split it out and apply it into multiple accounts.
And again, the above Access form is not based on views or even sql queries, but each part we placed into the form is based a single linked table.
So it is the slicing and dicing of bits and parts that you place into a form that allows and gives you the ability to edit related data, but each part is only based on a single table out of your elated data model.
It is “how” you cobble together these bits and parts that allows the magic of editing of related data. As such, this process and thinking on your part has really very little to do with building views that join together related data. In all of the above examples, I did not write any sql or create any views, and each part was simply based directly on a linked table, and not even some sql. So your related data model is a “guide” and will give you information as to what table and part comes next in building your user interface.
I know that you can save one form data to a specific table but I'm not sure how to do it for multiple tables. I've enforced referential integrity in my relationships but nothing happened.
Well, you likely need to add a bit more information.
As a “general” rule, a form is bound to a table. It lets you edit, or add records to that table.
However, given that Access allows you to deal with relational data, then to save records to “more” than one table, those tables will follow the “relations” you setup between those tables.
So for example, if you have say an invoice form, then the top part of the “main” form could (would) be bound to the table “invoices”. And for each invoice, you have “detail” lines. That is a table (likely called table: InvoiceDetails).
So your result is a form like this:
So you never really make “one” form write to multiple tables, but you most certainly will build a form and add additional forms to that one form. These “additional” forms are what we call “sub forms” in Access.
The “base” concept here is that the form will “appear” to update multiple tables, but the form is in fact made up of MORE than one form. These additional “sub forms” are how you edit (and add) related data tables in Access.
In above, the top part (our main form) is bound to table “invoices”, and each line of invoice detail (table invoiceDetails) is a sub form below. And access forms can display one record, or “many” records. When you need to edit (or add) multiple records to a table, then you create a “multiple items” form (let the wizard create the form for you).
Each form is as a general rule “bound” to one table, but by cobbling together multiple forms into “one” form (as related sub forms), you achieve the goal of editing data in multiple tables.
So above is just really a regular plane jane Access form. However the "repeating" details part is another form (a sub form, and is a multiple items form).
I have the following situation:
I have a many to many relationship.
For example an Employee Table, an Course table, and an relation-table inbetween.
Now I want that the user can select out of the course table his courses in a dialog form.
That means that the underlying table for my continous form inside the dialog is the course table.
I want a checkbox in every row which indicates if the course is selected or not.
As I read it is not possible, to add an unbound checkbox, because they are just copies, and a select click would select all of them.
The solution would be to add an yes/no field to the underlying table courses.
But here I have the problem as I understand the matter, because I have several users using the database at the same time, that the underlying table will be updated if I click one checkbox and this update will select the value for all users which are using the dialog form concurrently, what I dont want.
So my question is, is there another solution to get a working checkbox per row in a multi user access database.
There are two solutions which I could imagine:
1) The underlying table will be the relation table and in this every possible combination between employee and course will be saved together with a yes/no field. (but that would be from a data view point quite horrible)
2) If the changes to a checkbox would not be directly written back to the database table, I could discard them on saving and manually insert the relation records in the relation table. (Is that possible?)
Thanks for any solution proposals
I see two good approaches:
1) This assumes that your database is split in a network backend + each user has a local frontend. This is the recommended setup for multi-user.
The frontend has a local table with Course_ID and a yes/no column.
A join of this local table with the Course table is the recordsource for your continuous form.
On loading, you copy the course ids into the local table, and set the existing relations to True.
On saving, you update the relation table.
2) Use a ListView control instead of a continuous form. It has inbuilt checkboxes. Loading and saving is done with a VBA loop.
Based on your description I assume your form has a LEFT/RIGHT JOIN in its data source where some ID field is null if the specific Course/Employee combination does not exists in your relation table. Let's call it LinkID. Then your checkbox should be something like =NOT ISNULL(LinkID). While you will not be able to use the OnClick event for the user to check/uncheck this way, you can use the onMouseDown event to see if the user clicked the checkbox and take action accordingly.
That way you don't need an "all combinations" relations table, no temporary table and no Yes/No field. If a record with the Course/Employee combination exists the box is checked, if it does not exists, it is not checked. Adding and removing courses is done by adding and deleting records from the relation table.
Have a look at this How to use unbound checkbox in a Continuous Subform - MS Access. A class that binds an unbound checkbox. Better than listbox, because you have a form with all its benefits (sort, filter, edit, append).
I'm designing an Access 2010 web database, and I'm trying to create a subform that will display data based on joined tables. It displays alright, but I can't modify the data. The two tables are called Consortiums and PrincipleInvestigators. There's a many-to-many link between them, so I have a ConsortiumsPrincipleInvestigators join table.
I have a "consortium" form which displays the data related to a specific consortium, and has a subform within that form that displays the principle investigators part that consortium. I was able to successfully all the PIs, but when I try to add a principle investigator within that subform, it gives me an error: "Cannot add record(s); join key of table 'PrincipleInvestigatorsConsortiums' not in recordset. What gives? I imagine it's because I need to update both the PrincipleInvestigators table and the join table. (Also, MS, why can't I just use standard relational database stuff instead of this silly lookup field business?) Here's some screenshots of my table layout and my join table:
http://i.imgur.com/j4RJQ.png
Bleh. I feel noobish although I've done a decent amount of database projects, but the lookup fields and query builder is throwing me off. Does anyone know of any good tutorials on how to design queries?
There is really nothing that changes in terms of building a relationship between two tables. The fact that you use a GUI, a SQL DLL command, or now some relationship wizard changes nothing.
I mean who cares what the process is much to setup a relationship between two tables?
I mean, in client based you could type in something like this:
ALTER TABLE Cars
ADD CONSTRAINT MyColorIDRelationship
FOREIGN KEY (ColorID) REFERENCES Colors (ColorID)
So, now you use some wizard that is a few mouse clicks and this is some big deal? Really, who cares! No big woopy here, all we care is that you execute some command, or some wizard, or something here and you at the end of your day the result is your beloved relation between the two tables.
Check out the following video of mine where I "hook up" some existing related data into a web database. And I ALSO share how you can printout the related tables using the Access relationship window for a web database:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
So, at the end of the day, no need to get twisted up in some details of having to use some DDL sql command, some GUI relationships window, or some wizard. All you are doing as the above video shows is hooking up some tables and setting up a relation – nothing more, nothing less to worry about.
As for how to add child records that are to be related to a parent record? Well, in the past for the last 18 years, quite much every bird, dog, and beetle using Access would simply do this:
a) Create a main form based on the ONE main parent record table. There is NO NEED to build a query here, and in fact NO need to build a query that is a join of the two tables – this was never required and is not required. All you do is build a form based on the one simple table. We are done this part "a".
b) Create a form based on the ONE child table. There is NO NEED TO build a query here, and in fact NO need to build a query that is a join of the two tables – this was never required and is not required. All you do is build a form based on the one simple table.
c) open up first form (the form based on parent record table) and then in layout mode, now drag + drop in the child form from the nav pane.
The above a,b,c steps is how virtually EVERY parent to child setup in Access I seen done, and this long time forever setup CONTINUES to work 100% in web based applications.
In both cases (web or non web), the setup remains the same, the setup does not involve building quires, and the setup does not require ANY coding on your part.
As long as the link/master child settings are correct in the sub form control, then you are free to add child records to the child form and Access will do the rest of the dirty work of setting up and maintain the relation for you by setting the FK column in that child form for you.
So, how the basic setup works here has not changed in 18 years of using Access, and as such this does not change when building a web form here.
You don't need a query based on more than one table, and in fact JUST like in the past, the two forms will as a general rule will have their data source based only on the one table.
So in most cases there was never a need to even use a query for that one table that the form is going to be based on. This long time basic approach and setup has not change for web forms either.
In your case I would assume the main form is Consortium. You child form could be a continues form based on Principleinvegiartors. And in place of having to manually enter some PrincipleInvetigaor ID, you use a combo box based on table PrincipleInvetgioars. However, again in all cases, we are simply building forms that are based on a single base table.
For this situation, you should choose one of your tables for the main form and the junction table for the subform.
For example:
Main Table
Consortiums
Subform
ConsortiumsPrincipleInvestigators
Link Child and Master Fields ConsortiumID
ComboBox on subform
Principal investors
Row source: SELECT InvestorID, InvestorDetails FROM PrincipalInvestors
Control Source: InvestorID
Bound Column: 1
Column Count: 2
Column Widths: 0,2
Some notes on Not In List
DoCmd.OpenForm "AddSomething", , , , , acDialog, AddData
If Forms!AddSomething.Tag <> "" Then
frm(cbo).Undo
frm(cbo).Requery
frm(cbo) = Forms!AddSomething.Tag
AddCombo = acDataErrAdded
Else
AddCombo = acDataErrContinue
End If
DoCmd.Close acForm, "AddSomething"