There is access datasheet sub-form and users should only be able to edit count column. How can that be done ?
Currently, If I change the form property Allow Edits = True, users can update any cell.
Also, the user should be able to enter different count values. If a user types 1 in first cell, it get copied for all the rows.
How can this be achieved?
For each control on the form that you don't want editable, set the Enabled property to False (or the Locked property).
For the count copying to all rows, we need to see the query that this datasheet is based on to answer that. If the count is an unbound textbox, you will get the behavior you are seeing as Access will only create a single instance of the control, then repaint that single instance across all rows (note that this is the same with continuous forms as well)
Instead, create a query that has this field (or a dummy table) and bind to that, making sure to bind the textbox to the dummy field, and then you should be able to edit the value on a per-row basis.
I have a very simple form with a combo box that is populated by a query. A user selects the class for which they want to enter data from the combo box and the records (passing the selection from the combo box to another query) for that class are loaded into a subform.
However, when multiple users are accessing the database and another teacher selects another class from the dropdown and starts entering data, the subform for the first teacher requeries and brings up the class selected by the other teacher.
How do I avoid this?
I have split the database into frontend and backend.
It would seem that the combobox for selecting the class is bound to a field in a table. That is why it is updating for one user when another user makes a selection.
You should make this combobox unbound (=clear the ControlSource property).
It is not clear to me if you are already doing this, but the correct way of filtering by a field (class in your case) is to set LinkMasterFields (of the subform control) to the name of your combox control and LinkChildFields to the class field in the the underlying recordset of the the subform.
I have a form that contains 4 subforms. The first subform gets data based on a selection in a combo box on the main form. The second subform gets data based on the first subform, and the third and fourth subforms get data based on the first.
It's a database contain information on research grants. I want to be able to pull up certain data based on a person's ID (multiple records to a person) or by the title of the grant. Names are working fine, but searching by title is giving me a hard time.
I've tried setting first subform's Record Source with a .RecordSource ="" line, but nothing updates at all when the code runs (the code is in the AfterUpdate event of the combo box containing grant titles). This one has me sort of stuck; I'm not sure if the dependencies among my forms have something to do with it.
Did you put a Form.Refresh in after you updated the recordsource?
I have a form that is linked to a table in Access. I have an additional field which displays the sum of a few fields in the table. This field on the form is not connected to the table. I have the sum displayed on the form but what I noticed is that the sum does not appear until I move away and navigate to another record and come back to the original record. I don't see the addition as soon as I enter values in the respective fields.
Can someone help with this issue?
It sounds like you need to add some code to the After Update events of the controls for the fields used in the sum. That code can call the .Refresh method of the control that performs the calculation and update the total.
Edit
Another possibility is that there could be ambiguity between control values and field values if they have the same name. In Design View for a report if you drag a field from the "Field List" and drop it into a report then Access creates a report control with the same name as the field. This can confuse matters later because if any expressions refer to =[SomeColumn] it's not clear whether that refers to the field or the control. Often simply renaming the controls to something like txtSomeColumn can help if a report is acting strangely.
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.