volgen :)

I think I would approach it a different way.  I would have 5 fields in tblTechRates: TechRateID (Primary Key); IDTechnicians, RateStartDate (used as the start date), RateEndDate (used as the end date for that rate), RatePay. This table then would hold the historical data for the Pay Rates for all the employees.

On your continuous form, you could have two fields: (1) SuggestedRate (based on a query, based on tblTechRates, where the IDTechnicians matches the ID for the selected tech and the RatePay which has a Null value as the RateEndDate); and (2) ActualRate (could have the default set to the SuggestedRate, but could be edited).  Of course your underlying table would include the ActualRate, and if desired, the SuggestedRate.
Hope I have understood correctly what you wanted to accomplish (determine the current RatePay for the selected Tech; retain historical RatePay for each Tech; and allow the Rate field to be edited if desired).  Hope this helps.

You said "[Rate] from tblTechRates", but your list of field names for tblTechRates doesn't include "Rate".  Do you mean the "RatePay" field?  

Assuming it's the RatePay field, you need two domain aggregate functions (one nested inside the other) for this tricky situation: DMax to find a tech's most recent rate change date, and DLookup to find the rate for that tech on that date.  DMax needs to be nested because it needs to be used as a criteria (criterion?) for DLookup:

     Dlookup("RatePay", "tblTechRates", "IDTechnicians = " & IDTechnicians & " AND RateChangeDate = #" & Format(DMax("RateChangeDate", "tblTechRates", "IDTechnicians = " & IDTechnicians), "m/d/yy"))
    
There are better ways to do this, such as with VBA.  If you want to use only domain aggregate functions, the above is the way.  But this could hurt performance if your tables are big and this expression is used many times.

@ Paul: I will have to consider this tomorrow when more brain cells are online, thank you!

@ Kevin: Thank you, and sorry - i was trying very hard to keep all those straight, but apparently failed. Though i have programmed extensively in Excel (Yet still need frequent assistance due to my memory not being all that solid), i would also prefer a VBA method of attack - at least i have a foundation to make sense out of that! I was trying to nest a DMax within a DLookup, but after a while getting nowhere i knew i was just shooting in the dark. If i were in Excel i could use a find and a find next to go through a column (fields) and evaluate one date against each other, or simply filter the table to that tech, find the row that the max date is on and pluck the value from there, or probably ten other ways to play with it that i might think of when i wasn't so tired, but i really don't know how to address a table in Access in a similar manner that i would address a table. formal or not, in Excel. I will have to run some searches to find this information. Thank you!

Both great ideas, both i can learn from, and i thank you each very much-

-Bruce

In reference to VBA and Access tables, i would best guess that the interface is SQL (please correct me if there is another means), which would then lead me to think a SELECT with a WHERE that stipulates the individual's ID but then we would be back to an AND along with somehow somehow building in a MAX again, and given i am just scratching the surface of SQL i really shouldn't try to think when i know i once again am shooting in the dark...

Bruce,

Kevin gave you the final solution you were asking for.  For me, working through situations like this, I use a modular approach to tackle complex problems.  I will build a temporary form with a few text fields and develop the domain functions separately.  Once the parts are all working, I will start nesting them until I achieve a working final solution.  The domain functions are not difficult but I find they are tedious.  It has gotten better as I use them more.

If I want to work with an SQL solution, I use the same modular approach.  Make an aggregate query to find max of RangeChangeDate. Verify the data is what you expect.  Go back and an IDTechnicians criteria to further limit it to the technician that you need and verify that it returns the data that you expect.  Once this is functioning as you expect, you can then go to the SQL view of this query to see the SQL.  

I hope this helps.

@Kevin - So, you were testing whether or not i was actually going to work with the DLookup example you provided and see if i really wanted to learn from it by omitting that second "#"!

Using Matt's approach for SQL modular analysis, an excellent approach to the understanding of any larger system, all is working great.

Unfortunately, though I understand well the logic construct, i am afraid my learning and memory of syntax is very slow...

Thank you, all!

P.S. - i "enrolled" in a class so i could reply to you. Certainly not a waste of money, i honestly only became a "Silver Member" because i wanted to give back to Richard for all the shortcut help i have gleaned from his videos in getting back and running with Access after all these years-

Nice for catching the missing "#".  And that reminds me: you can omit the "#" if you put DMax inside the string as shown below.  But you have to double up all the double quotes:

     Dlookup("RatePay", "tblTechRates", "IDTechnicians = " & IDTechnicians & " AND RateChangeDate = DMax(""RateChangeDate"", ""tblTechRates"", ""IDTechnicians = " & IDTechnicians & ")")

Another example to make this clearer.  Instead of writing:

     DLookup("MyField", "MyTable", "MyDate = #" & Format(Now(), "m/d/yy") & "#")

you can also write:

     DLookup("MyField", "MyTable", "MyDate = Now()")