In ms-access 2007, i'm trying to make a form for a table. this table has foreign keys from 2 parent tables. so i thought i would make these fields a lookup. but i couldn't create a single lookup for each parent table because they are composite keys.
I decided to create a query in which for each of these parent tables and the child table with an extra field for each composite key. this works fine with a normal form using an unbound ComboBox... but the unbound ComboBox does not work in a DataSheet Subform. when i make changes to a ComboBox in the Subform code, they are applied to all the other ComboBoxes in the same column as well.
My questions:
is there a way to change the values of the individual unbound ComboBox?
is there a different control i should be using other than the ComboBox or the DataSheet Subform?
what is the normal work around for this situation?
I cannot bind the ComboBox's because the field from the query is calculated/an-expression as I said.
I ran across a form of this problem myself, so for the sake of posterity:
While generally, the advice "Don't use continuous forms/datasheets in this situtation" is the best advice...It is possible to work around this.
However, access will not let you update the value of a single control on a datasheet. What can be used instead in this case is a temporary table, which can, when used as a recordsource, become the values of those controls. You will need to repopulate the table, and requery the controls (requerying the entire form should work as well) every time the calculation needs to change, however. Furthermore, should you enable editing on the controls, you will have to write some VBA on each control to handle the update event (Before Update), and run your own query to update the source tables, not merely the temporary table. Annoying to do perhaps, but effective.
There is another possibillity, which may also work, but I haven't tried to do something quite like this myself. The rowsource of a combobox can be very complex, so it is probable that you do not need to update the comboboxes with VBA at all. The rowsource can depend on other controls (such as another combobox) using the syntax Me.Form!controlName or Forms!FormName!ControlName, which will allow you to form the composite key. Of course, you can also select from queries with a rowsource. What is more interesting is that queries can reference controls on your form, provided the form is open, and you should safely be able to modify that with VBA should you have to.
Between the two of these, you should be able to force access, kicking and screaming, to display any data you wish, even on a datasheet, and to allow the user to change that data (but only if you want it to), and using the BeforeUpdate event, drag modified data back to whatever table it came from.
Continuous forms and datasheets do not work well for editing in situations where combo boxes need to be changed conditionally. The problem is that if you use the OnCurrent event to set the Rowsource of the combo box, it will be OK for that row, but will then hide the stored values for other rows.
The solution is to never use continuous forms/datasheets for editing data when this is the case (I hardly ever use them for editing, in fact). You can create two subforms, a continuous/datasheet subform that functions as a list, and a detail subform, that displays one record. Make the list subform uneditable, and the detail subform editable. You can link the two of them by using the Link Child/Link Master property of the detail subform control, and set it to the PK of the list subform.
If your list subform is Me!List and your detail is Me!Form, and the PK field is MyID, your link properties for the detail subform would be:
Master: Me!List.Form!MyID
Child: MyID
When you move to a different record in the list form, it will be automatically loaded in the child form. Any edits to the previously displayed detail will be saved before record departure.
Related
I have a checklist that is used to perform QC audits. When a reviewer answers a question that requires an exception, a pop-up form will open with the correct exception detail already populated. They then have to provide some further information, which I have set-up in the format of a combobox for a field named 'Condition_Detail.' Some exceptions have only one condition that would be an option in the drop-down whereas others have multiple possible conditions, which is why I don't have that field automatically populated as well. I have a table of possible exceptions and conditions that I have used to create the combobox query. When the database was created, the field the 'Condition_Detail' combobox is dependent on was labeled 'Exception Detail' with a space and in my new table it is called 'Exception_Detail.' I did this because the old data and tables will eventually become irrelevant and I know that it is easier to write code with underscores instead of spaces. I include this information because I had to create a relationship between those two fields in the combobox query so that the database would know they are the same. When I test the database, the form opens as expected with the exceptions already populated (NOT in combobox format - the data appears as text on the form). The issue is that when I select the combobox, it is blank. If I answer the exact same question the same way to trigger the same exception to open in a new record, the combobox does have the correct data in it. I have tried to requery the field both when the form loads and after it updates. It still won't show the combobox values unless I trigger that the form open twice with the same detail populated. An additional piece of information that likely doesn't affect the problem is that the combobox is set-up as three columns so that I can populate two additional fields when the condition detail has been updated. I used the code below to populate that, which works perfectly when I can get the condition detail to appear in the combobox:
Private Sub Condition_Details_Change()
Me.Responsible_Position.Value = Me.Condition_Details.Column(2)
Me.Severity_Description.Value = Me.Condition_Details.Column(3)
End Sub
Thanks in advance for your help!
I figured it out. The relationship I created within the combo box query was unnecessary. The query was searching for values in the table that stored the actual responses/conditions instead of the table that stored the available response options. Because of this, once I had answered the question it knew what to look for, but in the wrong place. Setting up the combo box the usual way with the look-up control value in the form referenced as follows was sufficient to get the combo box to work properly.
Field: Exception_Text
Table: tblPreCloseExceptionDescEnc
Criteria: [Forms]![frmEncompassExceptions].[Form]![Exception Text]
I am looking to see if there is an easy way to rename subforms. I have a single form with about 8 forms, and 8 queries running each subform. I want to systematically rename each form and query I thought I had done this in the past though when I rename a form or query I get the error regarding the subform is missing. Obviously this is caused by the fact that I broke the link between form and subform.
Normally if this was just 1 or 2 subforms I would just remove the old ones and add the new ones back in there. Though As there are so many on this form, I would rather avoid having to do that if possible because each form also has to be arranged a specific way since this will be converted to a PDF at some point.
TL:DR I want to rename multiple subforms without having to re-add them back onto the main form (if possible)
Open the main form in Design View
Select a subform control (make sure to select the control, not the form it contains).
Open the control's property sheet and select the name of the new form from the Source Object dropdown.
You will need to perform steps 2 & 3 for each of the 8 subform controls.
If that's more effort than you want, look into the Track Name Autocorrect property in the database options. I'm not sure whether that would automagically update the subform Source Object property when you rename the form object, but it shouldn't take long to find out. Personally I mostly avoid turning on Track Name Autocorrect because it's been reported to cause odd behavior. If you use it, consider turning it on only when you need to rename a bunch of objects and turn it back off afterward.
I have an Access form with a subform that allows updating data in table X.
The subform contains a text box control named Y, linked to column Y in table X.
Now I thought that the table would be updated immediately after that text box control loses focus, but I noticed that this only happens later, most probably after the subform loses focus.
The point is that I need the table to be updated before (or during) calling the sub Y_AfterUpdate, because I wish to perform some standard subs/functions that rely on the table to contain the new data.
What is the best way of achieving this table update? I applied subForm.Requery and that worked, but there may be another, more intuitive method available. Note that Requery to me sounds more like "populate controls of the subForm, using the current table contents", and not like "update table and then populate the subForm again". Hence, intuitively, I would have expected that I should have used another method.
You want:
DoCmd.RunCommand acCmdSaveRecord
I have what I believe to be a common question about using a subform in datasheet view in access. My subform has a checkbox on it which performs some logic but checking any checkbox checks that checkbox for all the records. From what I see this behaviour can be altered by linking the checkbox to a datasource. However in my case the subform is based on a non-updatable query so binding to any member of the dataset results in the checkbox being uncheckable.
I am imagining some dastardly temporary table workarounds for this problem but they all feel like horrific hacks. Is there some way around this which won't make me feel too dirty?
So all the data controls, except that one check box, are bound to read-only query fields. And the check box is not bound to anything.
You could base your form on a disconnected ADO recordset. See this article at Database Journal: Create In-Memory ADO Recordsets
That technique seems less dirty to me than using a temporary table to accommodate the check box. Although you didn't tell us anything about the purpose of the check box, I'll hazard a guess this could work for your application.
this has me pretty confused and I can't find the answer anywhere else so thought I'd post here to see if anyone can help!
I have a form in an Access 2007 database with a subform (sfSubform) embedded in it. The subform control's SourceObject is set to be another form (fForm). fForm's RecordSource starts out as a table.
At one point I want to change the data displayed in the subform to the result of a SQL statement, so I use
sfSubform.Form.RecordSource = strSQL.
This works fine. However, if I ouput the name of the RecordSource for fForm after making this change, it still gives the name of the table that I orginially set.
Does sfSubform.Form.RecordSource not change the source of fForm? Is it a copy of fForm that is embedded in the control?
Hope all that makes sense.
The sub-form and the form each have their own record source (or are unbound). That's the whole point, actually -- the ability to present two different data sets. Typically the two forms have related record sources and this relationship is declared using Master/Child Link, but that also is optional according to the need.
So no, changing one won't cause the other to be changed.