Field is now read only after changing from text box to combo box

[Access_Novice]

In the attached database see the form "Master Form." Under the Parent section, the first field is called fullName. I changed this from text box to Combo box. The row source is the parent table with the forth column (full name) as the bound column. This column appears in the full name field.

Basically, instead of having a text box which will read in fullName values, I want a combo box that will list the same values.

When I change the fullName field to combo box and try to make a selection, I get an error that the 'fullName' field is read-only. I can't even make a selection. This occurs after I change this field to a combo box.

Why isn't this working?

[ItsMe]

It sounds as though the Control Source property for the combo is a field that is not updatable.

[Access_Novice]

It sounds as though the Control Source property for the combo is a field that is not updatable.

Yes, that's what it sounds like. However, when I checked the properties for that combo box I didn't see anything to indicate read-only. I checked the "fullName" field in the table called "Parent" and I didn't see anything there to indicate read-only either. When this control was a text box, everything was ok. But I encountered this read-only problem, only when I changed the text box to a combo box.

I can't figure out what is going on.

[ItsMe]

In the combobx properties there is a propertty called, "Control Source". What happens if you delete the Control Source property so that it is blank?

[Access_Novice]

In the combobx properties there is a propertty called, "Control Source". What happens if you delete the Control Source property so that it is blank?

If I delete the Control Source, then I am able to make a selection from the combo box. The data in all other fields remain. I just wanted those fields to update to the record where Parent.Fullname is equal to the value I selected in the combo box.

[ItsMe]

It does not seem that your query that has the field Fullname is allowing updates. Take a look at the query that supports the form. Look at it in datasheet view and try to update the Fullname field.

[Access_Novice]

It does not seem that your query that has the field Fullname is allowing updates. Take a look at the query that supports the form. Look at it in datasheet view and try to update the Fullname field.

You're right. I can't update it. I can't type over the existing values. But I'm not sure why this is the case. Any ideas?

By the way, the fullName field is a calculated field in its table.

[ItsMe]

By the way, the fullName field is a calculated field in its table.

This does not have any bearing. The query is not allowing updates because of the joins. The options are to create another query that allows updates or use something like DAO or an action query to update the field. You can employ DAO edits or SQL updates directly to the table using VBA.

[Missinglinq]

...This does not have any bearing. The query is not allowing updates because of the joins...

I'm not so sure about that, although that would have been my guess, too, if the OP was running an earlier version of Access. I don't run 2013, but a calculated Field on a Form, where the ControlSource is used to do the calculation, using something like

= [FirstName] & " " & [LastName]

is Read-Only, and I'm pretty sure when using the new feature in 2013, where calculated Fields are allowed in Tables, behave the same way.

I would

1. Delete the Calculated Field from the Table
2. Create a Query based on the Table
3. Create a Calculated Field in the Query for FullName, naming it the same as the old Field
4. Delete your Combobox and replace it with a new one based on the Query

You should now be able to make selections from the Combobox. Not sure what you're using it for, but if you need the FullName to appear on the Form, use the Query as the RecordSource for the Form, as well.

Since not storing calculated Fields is one of the cardinal rules of Relational Databases, I've never been able to figure out why the Boys of Redmond decided to add this feature!

Linq ;0)>

[ItsMe]

Good catch Linq!

I have chosen to ignore calculated fields in tables. However, this does not seem to change the fact that they do, indeed, exist. I believe they were introduced in 2010. I spent a little bit of time looking at them as I am trying to familiarize myself with newer versions.

Some features that do not seem to make sense are starting to seem relevant when I take into consideration trying to access a BE over a WAN. It seems a calculated field can be beneficial in a Sharepoint environment where querying several collumns of data to do a calculations can be expensive. Storing the calculations can improve the user's experience. Employing a "Calculation Field" is conducive to a RAD interface.

If I can find the time, I will look into Sharepoint and other ways to use Access over a WAN. There seems to be a trend here.

[June7]

Correct, calculated type field in table introduced with Access 2010. The value is generated by an expression in table field. Just like calculated field in query or textbox with an expression, it is not editable. Must edit the fields that are used in the expression. That field type intended to make calculations like Quantity * Price easier to work with. Build the field in the table then it's already available whenever table referenced.

The textbox bound to the calculated field would not have been editable either.

The FullName combobox on MasterForm is used to enter filter parameter. Controls used to enter filter criteria must be UNBOUND. Can use a textbox bound to field to display the value because can't always rely on unbound combobox to reflect actual value from the current record, although with this form setup with parameterized query, the combobox might be adequate.

However, the parameterized query isn't working because the parameter doesn't refer to the combobox name. Change form RecordSource to:

SELECT Parents.*, Gymnast.* FROM Parents INNER JOIN Gymnast ON Parents.parentID = Gymnast.parent WHERE fullname LIKE "*" & Forms![Master Form]!parentFullName;

Then need code in the combobox AfterUpdate event: Me.Requery

Suggest moving the combobox to the form Header section, although it should work in Detail section as well. Since you don't use the parent ID as parameter, could simplify the combobox to a single column.

Suggest you remove the FullName control from Parent form. It serves no purpose.

Since can't use Date() in table calculated field, Age field is useless.