A control in the Access world is just about anything you can put onto a form
or report: text box, check box, label, line, etc. Some controls such as
text boxes, combo boxes, list boxes, and check boxes may be bound to a
field, in which case they are bound controls. They may also be unbound.
Some controls such as labels don't have the option; they are always unbound.
An unbound text box is one that does not have a field in the underlying
table (or query) as its Record Source property. You can give it a name such
as txtToday. Thereafter you can refer to its content in code.
You could also use an Input Box instead of the text box. Check Help for
more information about that. The text box is probably the simplest choice.
Dim strToday as String, strHistory as String ' defines variables
strHistory and strToday as text
strToday = Me.txtToday ' the value of strToday is the contents of
txtToday
strHistory = Me.History ' the value of strHistory is the contents of the
History field
' The History field is redefined as the date plus strToday plus the old
contents of History
' Plus a few odds and ends described below
Me.History = CStr(Date) & ": " & strToday & vbCrLf & strHistory
CStr(Date) converts today's date to a text string. The double quotes
surround a literal value. vbCrLf moves to a new line. The apostrophe in
the code denotes remarks that are not part of the code.
When you wrote "I considered the multiple table approach but need to do this
project in a single table" it suggested to me that using a single table was
a design choice.
I was not suggesting a single History field in each record. I don't know
what history this is, but presumably the main record is about a person or
ongoing event or something that is updated frequently. My suggestion was
that each main record could have any number of History records. Each Today
entry would be separate record in the History table. Using the capabilities
of Access to establish related records, those History records would be
associated with a single main record, just as each pay record is associated
with an employee rather than being stuffed together with money, text, and
dates as a string of text in the employee's main record. There are many
advantages to this approach, one of which is that you can look at History
over a range of time rather than having to sort through all of the History
that was ever entered for the main record (the entire contents of the
History field in the current set-up). However, I don't know the purpose of
this database, so I can only guess about the purpose of History.