control can't be edited, it's bound to the expression

[Alla]

I have about 500 text boxes on the form, and since there
is a limit to number of fields that could be associated
with a table, I had to split it between two tables. Now I
have a form which is based on one of the tables, but I am
having problems entering info into the fields that belong
to the other table. In the Control Source property I have
something similar to =[TableName]![FieldName], but when I
try to enter data into the field I get "Control can't be
edited, it's bound to the expression" error. Any
suggestions? Using subform is not an option in this
case. Any help would be greatly appreciated.

 

[Ken Snell]

You cannot edit a control's value when the control's control source is an
expression.

If you want the control to put its value in a table's field, include that
table's field in the form's RecordSource and bind the control to that field.

If you want the control to be unbound but still show the value from a table,
you can use VBA code to obtain the value from the table's field and write it
into the control. This still allows you to edit the value, but it won't be
stored anywhere in this scenario unless you use code to write it to the
table's field.

 

[Rick Brandt]

I have about 500 text boxes on the form, and since there
is a limit to number of fields that could be associated
with a table, I had to split it between two tables. Now I
have a form which is based on one of the tables, but I am
having problems entering info into the fields that belong
to the other table. In the Control Source property I have
something similar to =[TableName]![FieldName]

That is an invalid Control Source. Which *row* would you expect to get from that
expression?

You could use a Dlookup() function to display the fields from the other table but
they would not be editable. To make them editable you would have to add the second
table to your form's query and since queries can't have more than 255 fields you are
right back where you started.

The only thing I can think of is to use a subform for the second table. Sounds like
a table design problem though. There is almost never a legitimate reason to have
that many fields in a properly designed table structure.