Paste current date/time into a memo field? 1

[thefourthwall]

Hello,

Have searched the forum and did not find a previous thread addressing this - thanks for bearing with me if I just missed it; am still a novice with Access, with all of maybe 3 weeks into it.

The form has field for client information entry, and a memo field for comments.

I would like a command button to paste the current time/date at the end of existing text in the memo field, to track any comments from a client's visit. Is this possible?

thanks,
thefourthwall

 

[edsuk]

Try this, replacing txtName with the name of the text box containing the memo field:

Me.txtName = Me.txtName & " " & Now()

The code is placed in the On Click event of the command button.

 

[traingamer]

That being said, it is a bad idea to have a memo field that you use to keep adding new data (granted, you did not say you would use it that way). It is a much better idea to have a separate 'Comments' table with an id field, a foreign key field, a date field and a comment(memo) field.

Why? I'm so glad you asked.
It is much easier to sort, find dates and use the data at a later time.

Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill

 

[missinglinq]

Assuming you want to "sort, find dates and use the data at a later time." Different people have different needs! There's many reasons for using a memo field where one can keep a running commentary with all entries at hand. Why complicate things?

The Missinglinq

There's ALWAYS more than one way to skin a cat!

 

[thefourthwall]

edsuk,

It worked - thank you! Being so relatively new to Access, it's still amazing to me to see the result of some code in action - this worked very well. Thanks again.

-thefourthwall

 

[thefourthwall]

traingamer,

I appreciate your input - the field is not to store complete information about a client - its to note incidental items such as the client was given an extra item at the time of his order (the database is for a food pantry that serves a poor neighborhood) and the like.

Having said that, I added the memo field to a table called tblClients, which drives most of what is on the form - this may be too broad of a question, but are you saying its better to have memo (comment) fields in their own table, along with a foreign key field, etc? Is there real value in having a separate table for that kind of thing?

Thanks,
thefourthwall

 

[missinglinq]

Traingamer's comments are valid IF you have or think you may have a need in the future to "sort, find dates and (manipulate) the data at a later time." For your use, to track a history, if you will, of incidentals provided the client, a single memo field is fine. Many clinical systems use the same technique for posting progress notes for patients. In point of fact, the Memo data type is designed primarily for this purpose. Most of the time data that needs to manipulated will be entered in standard text boxes. As I said in my previous post, different people have different needs!

The Missinglinq

There's ALWAYS more than one way to skin a cat!

 

[traingamer]

I've been bitten by very large memo fields on a couple of occasions in past jobs (in inherited databases with > 100,000 entries). If the memo fields are not going to be many thousands of characters in size and you do not need to search them often for particular dates, you'll be fine.


Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill

 

[missinglinq]

Inheritance isn't always a good thing! It's bad enough having to clean up your own messes, much less someone else's poor design! Reflecting on possible future needs is an often overlooked but vital part of database design!

The Missinglinq

There's ALWAYS more than one way to skin a cat!

 

[thefourthwall]

I doubt the database will contain more than 10,000 records and the memo field in question will never contain more than 10 lines of text per customer; in fact, in most cases it has been empty. From what I see, the particular memo field will *almost* never be searched, but your advice on the table structures is well received, and I appreciate it.

missinglinq: I appreciate your perspective as well, and have decided that the memo field can remain in its current table, given the context involved.

Of more concern to me right now is that I included a calculated field for each of the client's children to indicate their age; however, I forgot to bind that calculation to anything -- so the information shows up in the form correctly for each client, *but* the data is not stored anywhere, or so it seems ... worrisome since the data will be required for grant reporting ... sigh.

 

[PHV]

Why storing a derived/calculated value in a table ?
Especially an age as this value changes every day !

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[missinglinq]

PHV's exactly right in this case! The children's ages will change and may affect your results over time. Despite the prevailing opinion, there are times when storing calculate results in a table is appropriate, but definitely not here!

The Missinglinq

There's ALWAYS more than one way to skin a cat!

 

[thefourthwall]

PH,

Assuming I miscalculated in the way I setup the age fields, but since they are, in effect, a calculation on existing data, the calculation itself doesn't have to be stored anywhere, does it ...

I'm learning ... too slowly it seems, but getting there.

thanks,
thefourthwall

 

[PHV]

The calculation may be done in the query or in the form/report.

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886

 

[thefourthwall]

Got it.

thanks.