New Memo field in query

[nikki6f]

I would like to build a field in a query that connects data from many sources into 1 new field. It works fine 80% of the time, the exception being, it truncates after a certain amount of characters in some records. I am sure this is a size limitation, based on a text field. How can I designate this as a memo field?

Thanks in advance for your assistance. Nikki

 

[PHV]

data from many sources into 1 new field
How are you doing that ?

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

 

[nikki6f]

1st simple example, where [note] is my original stored memo field, then grabbing the date and new note from a form. I have others where I pick up more fields, like a collection agency name, etc.

NotesPlus: [Note] & " -- " & Date() & ": " & [Forms]![frm-CollAgencyMenu]![txtNotes]

If the Note field has very little to it, pre-update, it works fine.

 

[PHV]

Why doing this in a query instead of in the form ?

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

 

[nikki6f]

The long term intent is to create a log of this memo field, appending new info as we go. So the field "NotesPlus" is eventually appended to a table.

For testing purposes, I am using a report that I need it to appear on, but getting it to work in a query will make it work for all my eventual needs.

A different way to ask a similar need: I want to use a make table query. How would I designate a field as a memo in a make table?

Thanks for your help. Nikki

 

[lespaul]

so you mean eventually you are going to end up with a field that has data like:

--3/1/2005  Something that was entered on the form -- 3/5/2005 Another note was added today -- 3/10/2005 Another user needed to add some information -- 3/15/2005 Now we are really starting to get some data here --  3/20/2005  [b]You are going to get screwed someday having data stored in this manner[/b]

Some day someone is going to come to you and say something like: "We need to find all the notes that were entered in March that contain the word information" and you are going to have to spend considerable amounts of time trying to extract the notes that contain the month 3 and the word information.

You need a table that can handle a one to many situation. If this is a note about a specific person, then each person can have many notes, but each note refers to one person. Like this:

TblNotes
PersonID
NoteID
NoteDate
NoteDetails



Leslie

 

[nikki6f]

I hear you. That is exactly what the ugly notes box looks like. Problem is, I do not control the database format. It is canned software for 150+ users, currently a Pervasive database that we are upgrading to SQL.

My only connection is to batch update, saving the end users from manually keying in that exact type of data. In this case, sending items to a collection agency. Currently, our credit dept reviews a list, edits each client for 15-20 fields, controlling credit limit, status, what agency, etc, etc. This note field is info only, but still a valid item to be updated. I have the rest of it working smooth.

Wish I could control their format, but alas I cannot. There is also a long waiting this for this type of "upgrade" as well as a ridiculous fee. Believe me we store many items outside of "their" system to build in a more logic manner.

Any other ideas to control the field type?