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.
Related
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.
Ultimately the purpose is to allow the form to be filtered, (there's also a Refresh button on form). It is working well for me now, but I haven't seen this use of parameter queries before. I know I could use other methods (access standard functionality, use Filter/FilterOn properties with vba), but technically, is there a reason not to do this?
I'm not sure I understand your question, but parameterizing the SQL of your form to refer to the filter criteria controls on the form means you have to jump through hoops to display anything other than data that is filtered on all the parameterized fields.
The requery objection makes no sense to me, since you'd have to do a requery to filter the form based on the values in your controls, unless you're writing the recordsource instead of requerying it. If you're changing the form's recordsource, then I see no reason to use parameters referrning to the form controls that are used for typing in criteria.
Setting the form's Filter property is by far the easiest way to do that, but it assumes you've started with a recordsource that displays all the records you'd be selecting from, and that may be inefficient, or just a bad design.
So, basically, my recommendation would be to not use parameters at all, but to write the SQL dynamically and set the form's recordsource each time.
Parenthetically, in order to avoid the display of a blank form, you can use the trick of a TOP 1 query like this:
SELECT TOP 1 Null As Field1, Null As Field2
FROM MySmallestTable
That would have one record with Nulls in all the fields so your bound controls won't display error messages. It also makes the form uneditable without having to change the form's editing properties.
Well, I'd imagine you could write a VBA function to requery from the database based on an unbound text box in your form, though filter is a bit better suited for performance reasons. The only reason I can think of that you might not want to requery is if you are pulling a LOT of data from a MDB file on a network drive on a slow network with a lot of concurrent users; simply because the performance would take a severe hit. I could be wrong though
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.
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.
I have several forms linked tables via queries. The form pull data such as sales and ratios by selecting a product from the main's form's combo box.
I am however having to issues:
1- I would ultimately prefer the combo box to be a free entry; however by just entering in the box and hitting enter (not a button called “enter on a screen” which would initiate recalcs, just normal enter), while it does bring the new information in sub-forms it also changes the information in the original table. If I make the table read only that it just doesn't allow the form to work by saying that the table is read only.
2- The same Read only issue occurs when another user with read only rights tries to use the database.
I understand that ready only is functioning as intended, however I am wondering if there is way to make some functions work while disallowing the updating.
I am unfortunately learning on the go, so go easy plz.
Thank you
You need to make your combo box no linked to the underlying data, but once the data is changed, set/reset the value of the combo box. This way, if some types in a new value
A) it will not update the data whether it is updatable or not.
B) you can still have the subforms update based on this value
Private Sub Form_Current()
cmbMyDisplayOnlyComboBox = Me!WhatEverFieldHasTheValue
End Sub
Again, cmbMyDisplayOnlyComboBox Control Source is blank. Substitute the field that 'use' to be the Control Source as WhatEverFieldHasTheValue