Combobox #Name? Error

[AlexB123]

Hi all,

I have a combobox that is throwing the #Name ? error no matter what I do. There are two comboboxes on a single form, and the rowsource and control source are now set up similarly. One works, one throws the error.

I have removed a table from the database that the form property control source was set to ... is this the problem? Can I alter the form, or fix my properties?

Inside frmRegisterCreation, there are cmbClientID has ControlSource ClientID and RowSource SELECT tblRegisterClients.ClientID, tblRegisterClients.Client_Name FROM tblRegisterClients;

The other is cmbBOB with controlSource BOB and RowSource SELECT BOBID, BOB_Name FROM tblBOB;

Thanks for any suggestions.

 

[Micron]

that the form property control source was set to

I don't understand that statement. You mean you removed a table that was the form's recordsource? Then definitely could be the issue. Or you have an unbound control with an expression as it's source (such as one that starts with =) and a field in that expression can't be found. Or in that expression, you use a name that Access can't determine if it's a field or a control you're referencing, because you used a form wizard that named all your controls after the fields they're bound to. If I use a form or report wizard, I always go through the controls and give them proper names.

Last but not least, if you re-read what you posted, you'll see that you didn't mention which combo wasn't working when you posted their data properties. Maybe that wouldn't help a whole lot since we can't tell if anything about those data sources is missing or incorrectly spelled, which is another possibility. One wrong letter or extra space is enough to foul it up.

 

[AlexB123]

Hi Micron,

This is all related to my issues with the tblRegisterCreation. At the moment, I am looking at a copy of my DB prior to deleting the tblRegisterCreation. In the form, titled frmRegisterCreation, the Record Source is set to tblRegisterCreation.

In retrospect, that is clearly the problem. There is also a text box on the form, in addition to the two combobox's, and it references a column in the table I want to delete.

Is the best way forward to just rebuild the form? I have rebuilt all queries and edited everything to not look at that table.

 

[Micron]

While you could play with a copy of this form, it sounds like a do-over from scratch might be less of a headache for you. I would rename the old and keep it until done. You might want to keep it for reference when designing new.

If the form was very large/complicated, then modifying might be less work, but you'd have to know what steps to take. Either way, I'd keep the original as a temp backup.

 

[AlexB123]

The original form was bound to my problematic table, tblRegisterCreation. However, the two combobox's referenced other tables, tblClient and tblBOB, via select queries. All I need the combobox's to do is display a list of client numbers, or BOB's, so the user can make the appropriate selection, and hit a command button to produce excel sheets through VBA code.

Does this form have to be bound to a table? How does a combobox write data to a table if it's just a temporary selection?

If the table can be unbound, what do I need to keep in mind to get the form to have the same functionalities it had previously?

 

[xenou]

If you want the user to be able to choose an item from the combobox, you can either have the list sourced from a table (which is what sounds like is happening now) or you can have a list hard-coded into the combobox (essentially an unbound, static list that doesn't change - something that might typically be done for instance with a list like "Jan, Feb, Mar ... Dec").

So if you want to delete the tables but still have the list of items to choose from then possibly you can edit the combobox to use a static list instead.

 

[AlexB123]

The list was sourced from a table, tblRegisterCreation, and I'm trying to reimplement the same design and function from different sources.

Does a form have to be bound in order for its controls to be bound?

If the purpose of a form is to produce an excel workbook and save it, why would I want to bind the entire form to a specific table?

 

[xenou]

Does a form have to be bound in order for its controls to be bound?

Not sure. I usually think of controls as being bound. A bound form generally means that there are one or more controls on a form bound to a specific table. I guess at one extreme is a form that does nothing but display (and update, add, or delete) records from a single table. At another extreme would be a form that does all kinds of different things, including having somewhere in it at least one control bound to at least one field from one table.

If the purpose of a form is to produce an excel workbook and save it, why would I want to bind the entire form to a specific table?

I don't think there is any real answer to this one. Maybe you would, or maybe you wouldn't. It really depends on how the form is used. You probably could create excel workbooks even without any form at all, so it's just a matter of how you want to organize the process to get to your end result.

 

[AlexB123]

If a combobox is populated by sourcing from a list, and a selection is made, where is the data change saved? Should there be a table that records changes in this field for the control to work?

 

[Micron]

Does this form have to be bound to a table?
Does a form have to be bound in order for its controls to be bound?
How does a combobox write data to a table if it's just a temporary selection?

No.
Yes.
It writes a) by being bound, or b) via code

Bound forms are the easiest way to write to a table. Unbound forms can only do same via code - a lot more work. An unbound combo is usually used as a means of allowing a user to select from a list, and the chosen value is oft used to affect what the form and/or its subform displays. It can also be used in the writing process (append, edit, delete) as a means of providing a value to a query, or sql statement used in code.

A bound combo writes to the field it's bound to as soon as a) the control is updated or b) when the record is updated, so if you simply want the user to be able to modify data in the table field that it's bound to but control what the user can input, then binding it is OK. If you don't want to permit such immediate edits, then don't bind it (or do something else, such as disable/lock it if it contains a value).

When you refer to properties of your combo, you have to be explicit about what you're referring to - control source (what the control might be bound to) vs its row source (what populates the list). This isn't clear as it could be either

However, the two combobox's referenced other tables, tblClient and tblBOB

Not sure where we're going with this. It seemed like the original problem was that you "broke" it by removing a table and either had to rebuild the form or put the table back. If what you're needing now is how to rebuild the form and whether or not to bind it or its controls, I'd say the scope of that subject is too involved for a forum thread, beyond general questions. There are tons of web pages on bound vs unbound forms, which might be a good idea for you to look into.