Hum, both examples should work, but then again, why are you using eval() in
this case?
Virtually all forms, and all controls, and even all fields from a form,
report, or even a reordset can be referenced as a member of the appropriate
collection (learning about collections in ms-access is about like learning
about water when you want to try and swim!).
strReport = "Report1"
strReportFieldName = "T$CUNO"
now:
data = Reports!Report1[T$CUNO]
data = Reports("Report1")("T$CUNNO")
data = Reports(strReport)(strReportFieldName)
All of the above are the equivalent.
So,
strForm = "frmCustomers"
strField = "CompanyName"
forms("frmCustomers")("CompanyName")
forms!frmCustomers!CompanyName
forms(strForm)(strField)
Again, all the above are the same, and I see no reason to eval as you are.
(what you have should work..but, then again..you don't need eval())
dim rstData as dao.RecordSet
dim strSql as string
dim strField as string
strField = "CompanyName"
strSql = "select FirstName, LastName, CompanyName from tblCustomers"
set rstData = currentdb.OpenRecordSet(strSql)
debug.print rstData!CompanyName
debug.print rstData(strField)
Again, you can see that we virtually ALWAYS have the ability to specify a
string for a field at runtime, and no evel() is needed.
So, the very fundamental means to get at any ELEMENT of a collection has
always allowed the use of string. Note that even if you build your own
custom collections, then once again strings can be used here. So, the very
basic design of virtually everything in ms-access is a collection, and those
collections work just fine with a string variable. To resolve to a form, or
a report...I never needed (or tried) to use eval().
