Thank you.
I have some questions on what you did.
Okay, taking this from the top.
Concerning the convert commande :
So I've tried your convert code on your form and it works. I created the commande button to convert to CWY/SWY and it works.
However, when I create the commande button to convert TODA and ASDA. The code doesn't work at 100%.
For example : When I enter in the fields TORA=100, CWY=15 and SWY=6 I get TODA=10014 and ASDA=1006
Do you know why?
You'll need to cut and paste the exact code you used. (Please use code tags - they preserve formatting, making it much easier to read.) I just entered those same values into the attached demo database and came up with 115.00 and 106.00.
Also, like you, I have a runway ID but mine is a combobox. I would like to, when choosing a runway ID, to populate the fields TORA, TODA, ASDA, CWY and SWY with the value stored in the tables. Then let the user edit the value and save then.
I know I can use in the fields =[runwayID].column

but this doesn't allow the user to edit the value.
Do you know another way to populate the fields? And let the user edit the value?
Okay, time for a quick lesson.
The field RunwayID is a Primary Key. That means that it is THE field that the database uses to keep track of which record is which. As a result, values in this field absolutely, positively MUST be unique. I achieved this through use of a data type called Autonumber. This field type CANNOT be edited by the user; it is, instead, automatically generated and assigned by the database when the record is first created.
In addition, RunwayID is what's called a 'surrogate key': it is completely separate from the data and literally its only purpose is to keep track of which record is which. For lack of a better term, it's the 'label' Access uses when looking for records.
The table also contains what we call a 'natural key', meaning a field or combination of fields which uniquely identify each record. In this case, it's Airport and Runway Number. Every airport has a different code, and no airport has multiple runways with the same number. That means that every combination of Airport and Runway Number MUST be unique. So, as a result, if you open the table in design mode and look at the indexes, you'll see I actually created a unique index on those two fields because I'm sneaky like that. Also to ensure that there's no duplication, but mainly the sneaky thing.
Anyway, one rule that most of us agree on here is that primary keys, especially when a surrogate key is used, should never so much as be SEEN by the user. They exist to let the database keep track of stuff, and should NEVER be changed. Surrogate keys make this easy, while natural keys can occasionally be changed, such as what could happen if an airport expands, adds more runways, then decides to renumber them. Some folks would disagree, but I'm part of the 'never let them see a PK' crowd. If you want to let the users set the primary key, you can, but be advised that changing a PK can literally break a database beyond salvaging. All you need to do to make that change is to change it from AutoNumber to Number (it will default to Long Integer, meaning it caps at roughly 2 billion).
As to locating the data, instead of having the user enter a runwayid and then populating the boxes, you would create things like 'cascading combo boxes' (look it up, then come back if you don't get it), a list box showing airport and runway number, or a pop-up form listing all the airport/runway combos (just to give three examples), then use code to move to or filter to the indicated record. Or you could have a form that lists each airport and runway number combo, then opens a form, subform, or the like showing the detailed info.
For straight data entry, on the other hand, just have them add a new record (a quick way is to use the navigation buttons on the bottom of the form, and have them click on the one with a right-pointing arrowhead and a gold star, or you can create a command button that does the same). On the new record, they can just start entering data. (On my version, the RunwayID is generated automatically, so they don't need to worry about it.) Users can save data automatically by tabbing off the last control and onto a new record, by using the navigation buttons to move to another record, or by closing the form (among other ways), or you can add a 'save record' command button.
Concerning saving the value :
In your form it works. When you convert, it save the all the values in the tables. In my case, it tried adding If Me.Dirty Then Me.Dirty = False (I tried with True) and I tried adding DoCmd.RunCommand acCmdSaveRecord
None, seem to work. I wrote them between "End If" and "End Sub" and I tried writing it just before the End If.
I think, it's because it doesn't know where to save the data (like to which corresponding runway ID). Am I correct?
Mat
I'd have to see your form itself, but it sounds like you haven't bound the form to your runways table. If that's intentional, let me tell you right now, unbound forms are a LOT of work, and really not something an access newbie should try. If it's unintentional or it's bound but not saving, let me know.
Oh, and by the way: Welcome to the deep end.
