If statements on Access 2013 forms - ms-access

Okay, so I'm creating a new database, and I've written several queries that I now wish to link a form. A partial view of the form will be attached
What I want this form to do is when the user selects the manufacturer the model box will be a drop down with only models linked to that manufacturer
IE: If the user selects Dell they will get a list of only Dell products that I've added to the model table in the database. If they select apple, they'll only get apple models, and so on.
I have the queries written to separate the data already, I'm just lost at the syntax needed on the source control for the forms.
I've looked around Stack Overflow and found nothing, and I checked the msdn to see if I could find any clues, so far I've not been able to figure this out, so now I'm asking for help.

The setup you need is what is called as Cascading ComboBoxes - Filtering the records in one combo box based on the value selected in another.
With this, you will be editing the rowsource of the next combobox that follow, so it will be more like a filtered list, that gives you more flexibility to choose and filter. Hope this helps :)

It should be something like this:
select Modelname
from Models
where Models.Manufacturer = [Forms]![ManufacturerField].value

Related

MS Access Form Debugging

Hello I have a pretty intricate Access database. I just jumped on this project and have never used Access. I have a form that is generating a value entry popup when I try to run it and it shouldn't be. The problem is the form is trying to access a column of a table which has been changed recently. I just have no idea where to find the query or what exactly is trying to access that column. Any help greatly appreciated. I am using Access 2016 also.
Sounds to me like the problem inst actually your form but the query your form is based upon.
This may be a separate query or a query built in your forms record source.
Go to your form in design view. Open up the property sheet. (Under design tab) make sure the dropdown box has Form Selected and look at the Record Source.
The record source may state a query name, In which case you should remove the field/replace the field with another in that query.
Or if it says something along the lines of "Select ......" then just alter that query to not have the field you have removed/renamed and the problem should go away.
However it is worth noting that if you have sub forms it could be the record source of one of those.

MS Access - populate checkbox list from table

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.

Access: How to structure input vs read only forms

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!

How to recreate Northwind OrderLineItems type of form

I've been creating a database and adding forms.
My current issue is making a user friendly form where there are multiple subrecords, like 1 order record showing many related orderDetail records.
The Northwind Database has a nice example of this.
OrderLineItems is a simple form that fits into OrderDetail.
I opened a second version of Access, and tried to create a form that mimics OrderLineItems. I can't do it. I noticed two things.
In Northwind, many forms have a blue dot on the icon. These can't be opened in Design View. Why? It makes it harder to see what is going on.
No matter what I do, I can't seem to get the selectable options to even remotely line up in terms of quantity between the OrderLineItem and my form. There are about 29 (under ALL) in Northwind and WAY too many to count on mine. I'm trying to figure out what the magic selection is to make them match, but can't find it.
What's the best way to make a form setup like Northwind's OrderDetail with OrderLineItems?
Thanks

checked list box

I am new to Access and i am in the process of creating a database for some of our users. I have designed a form where the user name, first and last name etc are inputted.
Some of these users work for more than one department which means I need some type of listbox control that allows them to select more than one department when they enter their contact info.
In VB Studios 2005, this control is called a CHECKED LISTBOX. I have looked everywhere in access but cant seem to find it or anything closely similar.
The option of a listbox or combobox is not feasible here as these only allow the user to select one option only when inputting their details. Any help with this is much appreciated.
Use an ordinary list box with the "Multi Select" property set to "Simple".
The user can then click multiple list items, all of which stay selected until they un-select them again.
You may wish to consider a subform, as this will save you the trouble of updating a table with the data from a list box. A subform can use a department-person junction table with person id as the linked child field and master field. A combobox bound to department id will allow the user to select departments.
If you are really set on having checkboxes, Stephen Lebans has a sample database that uses the built-in Access listbox with checkboxes (from one of the Access wizards).
There is another choice:
If you are using Access 2007, you can declare your field as a lookup field accepting multiple values.
When you bind the list box to that field, you will get checkboxes.
It's easy to use them.
You'll also find more information is available from the MS Office website.
However, note:
This is only possible in the new Access 2007 database format and you will not be able to save your database to the older MDB format.
Multiple value fields are not compatible with most other databases, meaning that if you decide one day to upsize to SQL Server, you'll have to redesign your tables to use a junction table as Remou mentioned.
These multi-value fields are difficult to use from VBA: the value they return is in fact another recordset that you must iterate through to get all the values.
Having said that, if you just want something simple and you're not planning on manipulating the database from code, then it can be a practical option, albeit not a very compatible or future-proof one.
I'm not using them, but I think others should be able make their own decision knowing what is available to them.