1) So in a query or the control source for a form control:
- Query:
-
FieldName: getAgePhrase([AgeField])
In a control's property sheet, data tab, property [Control Source], provided the [AgeField] was in the form's record set or available in an unbound text box then:
- =getAgePhrase([AgeField])
You would not normally use this in a table.
>>> I would also not hard code the example you've given for the age range - it's hard to maintain. Instead I would have a table with these text results and a query that returns the value based on the criteria see (2). You might have to redesign the table structure as well as often when I see things like this hardcoded there is an underlying weakness in the database design.
2) The answer is both yes and no, see (1). If you use the function in a query, via the query editor (QE), you are using SQL, just that Access has hidden it behind a pretty dialog box. You can see the SQL script by right clicking in the table area of the QE and selecting SQL-View. (Select design view to go back to the happy place (^_^) )
3)That was the impression I had of what was happening. Even though everything is related, it's not always so direct which can be confusing and frustrating (even to us old-hands)! So in your case using the vba in order for the VBA (or Macro which is a 2nd language avaiable in Access) to have an effect on a record set there must be an explict value change. This can happen in a form if the control is bound to table/query and the VBA alters the value of bound control, the VBA opens a recordset and updates the values (can even be the form's recordset), the VBA uses the execute method on an action SQL (such as INSERT or UPDATE).
4) I'm going to PM you my standard list of what I hope are helpfull links. There are some tutorials in this that I highly recommend you take a careful look at (and hopefully work thru the hands-on one). There is a sublink in the hands-on one that works thru database design (in ACC2003; however, the concepts still hold true) that you might find of great help.