Ive got a peoples DB and after some development my recordset for the main form is not updatable because of subqueries etc etc..
All this is because i redesigned the DB to resemble real life more, meaning i added some tables that could track certain things. This made the relations a little more complex and now im left with a DB i cant add new records to or edit hahaha and thats pretty useless
So I'm left thinking it can't only be me so there is either a simple solution i can't see or i have designed my forms totally wrong.
Whats the praxis in design/structure when you have/get a form based on a recordset that's not updatable in a "regular" peoples DB and you want to add or edit details in it? (think HR managment DB)
(Reason for the recordset being un-updatable: The recordset is based on a query that gets records from 3 related tables and does a MAX function on a date field to get the most recent record on two of the tables)
Now i have a mainform and three subforms on it. I can edit/add info in the subforms of course but the mainForm displaying names and other personal details is not updatable...
The mainForms Query is querying the tblPerson, tblInmate, tblClassificationHistory and tblSquadHistory...
In your case, I would recommend two possibilities:
Build an extra form for input and edit data for persons where the only record source is tblPerson. This input/edit-form you can open in your main form via button or ribbon for example. You can build one form for input and edit data and change the behaviour by VBA-Code (or even Macros?). Or you can build two forms for edit and input data seperately. Also you can add OK and cancel buttons to safe or undo your changes. The possibilities are endless. This is basis ACCESS knowledge and there are tons of tutorials out there, so I will not explain this further.
Change the query on the main form. If you have a continuous form and you do not want to add a new form, you should edit your query. I can not estimate your described query complexity with given information, but there must be a way to get the "MAX-date"-recordsset without aggregated ("Group By" -Statement) query results. Your goal is to change your main-form query, that it does not have any "Group by" part. Be aware that you can use subquerys to do the "Group by" for finding the "Max-Value". You should also check your main form query, if you really need all queried fields for the main form. Let your three subforms do the data query work.
Basically, the perfect user interface (UI) as forms in ACCESS depends on the users preferences, expectations and the use case itself. So you have to find out, which design suits best for your application. You can do some research on UI design patterns if you want get knowledge from recent experiences. It is a huge field of expertise!
Related
I'm trying to create a small MS Access database to ease up my everyday job. The problem is I'm a noob when it comes to databases. I'm trying to prevent the user from accidentaly updating the wrong record.
I have a table of records, some of which are not 100% complete.
I created a query that lists only these incomplete records.
On a form, the mentioned query is fed into a listbox.
I want the user to be able to pick an incomplete record from this listbox and fill in some of the remaining parts of the record in a bunch of text boxes. What I don't like is that the record gets updated as you fill in the form fields (they're bound to the table) WITHOUT any request for confirmation. If the user picks a wrong record at the start, the records are gonna get messy with every text box filled. Or that's what seems to be happening.
Here's my idea of the user form:
Is there a correct way to do this? I could force it all with VBA but I'd rather avoid that and use a more native (correct) solution.
Thank you for any answers.
Table constraints are an important part of database design. Any grouping of elements that together are required should be in their own table. This way the required fields must be entered for every record in that table.
For each data entry step you will have one or more tables representing the required data of that step.
If you are following database normalization best practices this should be simple to achieve because your data will already be broken down in to small elements that can have required fields to complete each record.
If you have a record that contains fields that are filled out at different steps then that is a design smell that indicates your table is not properly normalized.
In MS-Access, the forms will follow these rules set in the tables. You will not be able to save a record that has required fields missing.
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'm using a local Access database. Let's say I have 3 tables -
Projects, Contractors, Project_Contractors (linking table, multiple contractors can work on multiple projects).
I'm building a form to be used to create a new Project entry. I want this form to have a checkbox list of all the Contractors, so the form will add a new entry to the Projects table as well as populate the linking table.
I'm very experienced with SQL, but not with Access. Is there a way I can populate a list of form options directly from the Contractors to complete this? I'm using Access 2013.
A listbox control is pretty good at accomplishing this. With larger datasets it can be clunky to scroll through them all, and if you can't make it tall enough to show all rows you also lose visibility on previous selections, but it's pretty easy to set up and link to the Contractors table (you should be able to do it through the wizard, or type some SQL into the control source).
Turning on the multi-select property of the listbox should do what you are looking for. MultiSelect Property
Getting the selections out of the listbox to generate your append queries I think requires VBA. Here's a link explaining how to accomplish it. Clicky
EDIT: to more directly answer your question, you could use checkboxes by adding a boolean field (there's a checkbox option there) to your Contractors table and use the table as a subform in your entry form. I personally think that's bad design, and the steps to clean it up make it way more complicated than using a listbox.
What is the best way to organize a big database.
The way it works is that only I am allowed to touch or modify the database but interns help sometimes to collect data, we used to have the whole system excel based, back than we had the macro which by choosing 2 files it will integrate and mark in colors the changes.
How can I create something friendly to use which will update by pressing a button and also will show changes!! I am familiar with the update query, however:
it doesn’t track any changes.
I want to know other options.
To sum up the way of processing is:
I have the database and I need to split some data to smaller files so other employees will work on.
Then I will collect the files and integrate with the existing database, but since we are all human mistakes can happened that’s why I want to be able to track easily changes.
The updates are going to happen often. When I will give the intern a temp. table The possible changes are for example: address, phone number, price, they will do those researches based on current data which they will find online which information has been changed, and they will change the info which is on the temp. table, That is why I want to be able to know what exactly did they found out. Lets say if Product A (product ID1234) used to cost 10$ and today its 12$ from the same supplier. I just want to know and to see that the price for product ID1234 has been changed. Not only to have it updated to the back end database. For quality assurance I need to track which new input they did in relation to the product ID. (some times input by someone else which was done in wrong format or wrong column could affect big time on the quality of the reports)
So this was the explanation for what I need the reports
So in order to make those temp. tables, I want to create a form for it that by choosing region, category etc. and then clicking on a button it will automatically select the relevant records from the database, create a new table/access-file and then copy the selected records to the temp. table. So someone else could work on it...
Next thing is that it would be nice to know how can I create a template for tables, by template I mean to standardize by validation rules. some fields I'd like to have dropbox menu, some fields ready mask for phone number.... etc.
Final part, after they made the changes and saved the file (the temp. table which they were working on), I want to be able to update the back-end database via clicking on a button...
Looking forward to get the best solution!
Thanks in advance J
Michael
Okay for the temp tables thing:
why not split your database in a backend part (having all the tables) and a frontend part which contain the forms and tables the interns need? I'm guessing mostly it is going to be the same so you can even create multiple different frontend's to give to different interns incase they need other tables. There are a lot of articles out there about splitting a database and linking tables.
Then the thing about the record changes not sure is this is what your looking for but it could help, i haven't used it myself so not sure what it exacly does. But this may help you a bit.
http://support.microsoft.com/kb/197592
I would consider taking a look at the BeforeUpdate event for the form. You can trap the old and new values of textboxes if the form is bound to a table. You could loop through all the controls on your form and check for Me.Control <> Me.Control.OldValue. If they don't match, write both values to an auditing table so you can go back and check whenever you want to. I would include the following fields in your auditing table:
ChangeDate
TableName
ControlName
OldValue
NewValue
Then you can query that table any time you want to see what has changed.
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"