Robert,
I haven't really checked exhaustively, but did generate a table with two years worth of dates and the query does fill in all of the 'seasons', and looks (at a glance) to be correct. Since it is a query aginst two tables, w/o intervening steps or operations, I would expect no other isues. Of course it will, by the very nature of the query action update all 'seasons' in the target table when ever it is run. Obviously, one needs to be aware of the need for an execution, wheather dates are added to the target table or alterations made to the seasons table.
You soloution (and code in general) is not my preference for updating numerous entries in a recordset. I have never been able to generate a code soloution to multiple updates which is faster than an SQL soloution, and have even attemppted to do so under 'test; conditions. Even using code, I would think it would be faster (and conceptually easier) to do a lok up (find or seek) than the loop to obtain the season for a single date.
e.g.
Code:
Public Function basGetSeas(dteDate As Date) As String
Dim rs As DAO.Recordset
Dim strCrit As String
Dim Quo As String * 1
Dim Pnd As String * 1
Quo = Chr(34)
Pnd = Chr(35)
Set rs = CurrentDb.OpenRecordset("tblSeasons", dbOpenSnapshot)
strCrit = "Format(" & Pnd & dteDate & Pnd & ", " & Quo & "mm/dd" & Quo & ") " & _
"Between " & _
"Format([dtSt], " & Quo & "mm/dd" & Quo & ") " & _
"AND " & _
"Format([dtEnd], " & Quo & "mm/dd" & Quo & ")"
rs.FindFirst strCrit
If (Not rs.NoMatch) Then
basGetSeas = rs!Season
End If
End Function
Of course, this leaves out the nicity of error detection and a few bells an whistles (and optional parameter for the dteDate?).
Briefgly reviewing the original post, I do notice that two TABLES are mentioned, so to use either of the 'code' soloutions would imply calling the procedure for each record. For trivial recordsets, the difference is probably un-important. For 'industrial' sized ones it would more likely be noticable.
As you note, the inquiry has not, as of this point, be sufficiently clear to know the final 'best answer', and it is quite possible that both approaches could be useful. Another basic tennant in db land is to NOT store redundant information, so since 'season' may be calculated from date and the seasons, then as long as it is not a high usage element it may in fact be better to use the date input approach.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places