I created a form with an unbound combo box to look up an existing person and then show their personal info (address, DOB, etc.) Which I assumed, that if need be could be edited. And I also thought I could use this to add a new record for a new person. But now I am wondering if I am better off having two separate forms. One form for adding new records only and one for editing existing records.

One of the features I have is that when adding a new record of a person, there is a button that then takes you to adding a new sale for this person that was just added.

One problem is that most generally all the persons information is available at the time of the sale so rarely do you need to go back and edit the person unless they move. So I am thinking for people, it would be best to just add new person in one form, then take you to the new sale form for that person. The problem there is that ALL the information for the sale is NOT usually available at the time of the entry. Usually you have to go back and add a sale number and sometimes an effective date. FYI, i do not want sales in a subform on the person form. It's not going to happen that way because the new sale then leads to more information for that particular sale (specifically commission.) Right now I have the next form (commission info) set up with a button to go back and add another sale for the same client because that is usually how it goes. But I may just make the commission form a pop up form that is entered and closed. I don't know, I am not there yet. I guess that is what I am trying to figure out.

Anyway, I am thinking that I should have some separate form that can be accessed later for editing/adding to- the sale information. And maybe because the person form is edited so infrequently, it should be separate form too. I don't know. I guess I began second guessing this because I was worried about how my combo box was set up.

I have an unbound combo box on each of these forms that searches the client my last name. Then when you chose the person it populates the fields. Is this the correct way to have this? Is as an unbound searching combo box even if I want to make edits? Or do I need a bound combo box for editing? It all so confusing. I am ready to build my forms and start entering data but I want to make sure they are right. My Persons form already has a subform to show multiple addresses--just in case that is relevant. I have tables that ties those tables together. Client table, address table. address type table, address link table.
I addition, I do need to create a third form that will have client info and the sale info subform together but this form has to be for search and then view the results only. Absolutely no edits will be made on this one. This is for people who have no idea what they are doing and will randomly start changing things and not know how or why they did.


Anyway, any advice on how best to proceed would be great.

Thanks all.

Kathy

well, it's best to approach the user interface from the standpoint of workflow: what will be the easiest, most efficient, and most accurate way for the user to access the records s/he needs at any point in the workflow?

for instance, when entering the sale of a new policy to an existing customer, does the user want to find the customer record in the system first? and how much information does the user need to see to be sure s/he has the correct customer record? after all, if the BOB is sizable, there's a good chance of duplicate customer names, especially if you're selling to multiple members of the same family group.

to update existing policy information for a customer, how will the user want to search? by customer name (see above re verifying correct customer record)? by carrier/policy number?

when the underlying data structure is correct, Access will support an enormous range of possibilities for the user interface. you're pretty much limited only by your imagination and your skill level. subforms, pop-up forms, tab controls, are some of the most common methods of presenting and controlling data. using one form or multiple forms, that decision is based on how the work is being done. again, we're back to process analysis; make sure you understand what the users will need to accomplish, and when, and how. then you'll be in a good position to design an interface to support their workflow. there's really no right or wrong answer, it's about meeting the user's needs.

hth
tina

Thank you for the reply.

Forms may change in the future, based on work flow. But for now, I am just wondering the basic question. Do I have it right....that an unbound combo box for searching a record, can also be left blank, to add a new record by filling in the correct data on the form. And/or used to find any existing record and edit the information that is found?

In my reading I keep coming across different things....that unbound boxes are for viewing and navigating. But a bound combo box is need to update or edit an underlying record source. IE: the table. Is this wrong or just depends on. something?

If the above is correct, it would mean that all editing or adding of new records requires it's own form with a bound box to the record source. That an unbound box would only be used to find a record and have the form populated with the correct information.

is there a quick answer?

Thanks Tina and anyone else who can help.

Kathy

"bound" means that a control's ControlSource property is set to a field in the form's underlying RecordSource; by setting a control's ControlSource property to the name of a field in the form's RecordSource, you are binding (or tying) the control to the field. when a control is bound to a field in the underlying table, then any additions/changes/deletions you make to the data in that control, when in Form view, will be written to the record in the table.

an unbound control does not have a fieldname in its' ControlSource property. unbound combobox controls can be used for finding or filtering records in a form. for instance, if you have an unbound combobox with its' RowSource based on a table that contains customer names, you can choose a customer name from the droplist, and write code that finds the matching record in the form - assuming that the form's RecordSource is based on the same table. or you can use an unbound combobox in a mainform - again, by setting the control's RowSource appropriately - to find or filter records in a subform.

the droplist of a combobox control shows data, of course. but this data is provided by the RowSource of the control, it has nothing to do with whether or not the control is bound. when you make a selection from the droplist of a bound combobox, it changes the value stored in the underlying field. if the combobox is unbound, then making a droplist selection does not change any data in the table underlying the form - unless you have written code to change data at that point.

hth
tina