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'm pretty new to Access and coding in general and I've been working on a database that was filled with data extracted from SAP.
I have a query that works as a way to "summarize" the information of a bunch of records from some purchase orders, it does sum the total of each PO, it's date as well as other information. It does consolidate a variety of items related to the purchase order into a single record that is displayed in a continuous subform for easy analysis in this structure.
[MES_CORTE][SOLPED][PO][FirstMIGO][TOTALPOVALUE]
This way, the user can preview easily each purchase order, date, value and other relevant information. This query is also used to generate some reports.
However, I want to be able of opening the source table ([Registro_OC]) and search the related records by clicking a field on the subform for a detailed view and posibly to edit or enter new data. is it posible?
I've tried to code some macros but can't figure out how to reference the table fields related to the query fields that are on the form.
Also, it seems that Access doesn't allow to create subforms based on continous forms.
Any help and opinions are appreciated.
I haven't worked in Access in quite some time. But, I have a report that has a main query, with grouping. The report is based on a database like this:
Each office has many divisions.
Each Division has many projects
So, I group by office. But, each division has a lot of other relationships I would like to include in the report. Like Staff members. Is there a way to create a secondary, and more, query and loop through that to add data to the report?
thanks
Yes you can do this with both forms and reports. You need the SubForm control. This allows you embed one form/report within another. You can also define which fields to join on. This allows the main/outer report to filter the sub/inner report.
The link above contains detailed instructions taken from the Office website.
I'm trying to make access conditionally only show rows that meet a certain condition, allow me to give you some background info before I proceed :
I've created an Access form and linked it to a test DB on my machine. The particular table I am interested in contains the following (important) rows :
ID , Office, Name, SecurityNumber
The thing is, ID is not unique. There are two Office locations, and each Office has it's own set of unique ID numbers. This means that ID 10 here and there may or may not be the same person. (this data comes out of a legacy security system we're not looking to change yet, so I cannot change it)
But ID -is- unique to each Office.
SO! I created an Access form with TABS! Two tabs, one for each office. What I am trying to achieve now is :
Have the ID/Name/SecurityNumber fields for each tab populate with only rows that match it's particular 'Office' value.
Thank you for reading and thank you for helping! :D
If you want the data for the office locations presented in separate tab page controls, you could use subforms on the pages which differ only in the WHERE clause of the queries used as their record sources. So for the Office1 subform, the query could be:
SELECT ID, Office, [Name], SecurityNumber
FROM YourTable
WHERE Office = 'Office1'
ORDER BY [Name];
Then for Office2, the query would be the same except for the WHERE clause:
WHERE Office = 'Office2'
As I understand your question, that approach would do what you're asking for.
However, that's not really the easy "Access way" to do it. Instead consider a combo box control to allow your users to choose which office they want to view. In the code for the combo's after update event, either modify the SELECT statement used as the form's record source or create a filter expression an apply it.
Also, since you're pulling the form's data from SQL Server, consider whether you want your form to load every record for the selected office location. It may not be much concern if you have only a few to moderate number of rows for each location, but if you'll be dealing with multiple thousands of rows it could be. In general, you should try to avoid pulling copious amounts of data across the wire; pull sparingly instead ... only what you need for the immediate task at hand.
The company I work for have an access database that is linked to a sql server table. The database is on a shared network location so it is used by lots of people in the company (with the annoying problem that only one person can use it at a time).
There are several forms that are used as a front end for the data and on one particular form there are combo boxes that are linked to other tables.
When a report is generated on the form the ID of the combobox is on the form (a GUID) and not the bound item of the combobox.
How can I get the bound items to appear on the form itself? The solution needs to be easy to do or something i can produce that can be regenerated as it's used by non technical people.
In order to make the database usable by many, simply give each user a copy of the front-end.
Forms should almost never be used for reports, the best thing to do is to build a query (the query design window will help) that references each of the relevant tables, for example, if the combobox contained a reference to person type and you might build a query like this for your report:
SELECT a.ID, a.SName, a.MainAddress, c.PersonType
FROM Addresses a
INNER JOIN PersonTypes c ''Or LEFT JOIN if data is missing
ON a.PersonTypeKey = c.PersonTypeKey
If this is not possible, perhaps you could explain in more detail exactly how the report is generated from the form.