Search results

For me, the subform is a form filtered. Otherwise, i dont see the point for a subform. Also, i think that your subform doesnt show records becouse the primeri filter for the subform (i am sure that there is a filter) returns no values for the filtered records in the form.

I suggest another table, related to the customer table in witch you will enter the schemes using a subform.

You know that all that "scheme" boxes should be fields on a table. Is there a limited number of schemes? Maybe you can use another strategy. Tell us more on what you need to obtain from the db.

Or you can upload your db and maybe someone will help.

You'll have a value on the combobox, right? That value can be stored into a field from a table. That field can be selected on the wizard of the combobox. Use the wizard. Read the text on the wizard and you will get it. Is pretty clear.

I guess that you have more then a skill table. Maybe you have a employee table to. You need to create another table to combine the two tables. That becouse one employee can have more skills and one skill can be on more employees. Then you have to think of the queries you need.

If you use the wizard to create that combobox, at one step you'll have to chose where to store that value. That is the easy way to bind that control.

I know it's possible but you'll need help from someone who knows a lil of VBA. That is not me. :)

I assume that that combobox is unbound (no control source). Right? If so, you'll have to know that this kind of fields will act like this. Is nothing you can do. Maybe we can help with a solution if you tell us what you need from that combo box to do.

That error that you mention is the error message that appear when you are on the last record and you press next record button. The same with the previous record button when you are on the first record.

I see that the buttons work ok. What is not ok is the relationship betwen the two tables. I suggest that in the tract table you replace unit_name with unit_ID and create a one to many relationship. Then you'll recreate the forms and all will be ok.

Too bad. Tat will make room for mistakes.

Agree! But the suggestion was for the form in with is obtained the confirmation#.

Imputing data into a table doesn't populate other tables just becouse of the relationship created betwen the two tables. I think you have this all wrong.

can you attach you db to see the problem?

For your other demand, i sugest you to change yes/no fields with lookups filed based on the letter (A or T or any other) and a blank space. This is the simplest solution. If you insist on yes/no field, you can use IIF function under the control source.

Like John Big Booty says, i see no reason for you to store it. Also, till the 2010 version, Access doesn't allow calculated fields into the tables. Just use the formula in any report or form you will create and need to show that confirmation value. Even if one of your filds is a yes/no field...

Here it is a db saved as 2000 version

I have atached a simple db that contains the necesary infos and a form to insert more. The others info from the excel file (the first 2 sheets) dont need to be inserted into the db. That info can be obtain from queries. I hope you can create some queries that will help you view the necesary info.

I don't understand the combos: on each combo you have the same things to choose from? Maybe it will be more simple to use each combo for a different thing: cbo1 for YEAR, cbo2 for LOCATION and so on. Then you create a query that will have filter criteria for the fields based on the cbo.