You'll want to work in memory because it will be faster and will diminish the memo bloat that naturally occurs each time a memo field is edited."
A solution to this situation is when done PACK the table and the bloat will be gone.
BTW: I have started to use this technique. I have one and only one table in my database (I use the term database lossely as I do not use a DBC, my database is the collection of free tables that make up the application's data. ) that has a memo field. It is the Notes table. It also has a field name "Note_Frag" (Fragment) a Character 100 field. When a note is <101 characters it goes into the Note_Frag, otherwise the full memo is used also. (There are several other fields such as a PK, Master_Table_Name, Note_Name etc. )
So far 90+ of the time the Note_Frag is used and therefore the actual Memo information is keep shall we say cleaner.
The 100 characters is a number that seemed best for the apps I am working with, other apps might find 50 or 250 or ?? a better fit. Basically I am finding the majority of the information in the apps I am working in a memo field to be < 100 characters, thou there is that <<1% that are 100,000 characters.
I have been using this idea for a couple of years and while there is a little more programming to start with I find the benifits are great.
-In many cases I may need a copy of the main table data, but no need for the memo, e.g. faster transfer times
-If the memo becomes corrupted I have at least the Fragment information.
-I can display to the user the Fragment information in a grid a little easier then having it in a memo
-Total file size is smaller (Less Memo Bloat)
-Only one table to pack to remove memo bloat if needed.
-Yes it does make SQL selects more complex and possibly slower but on the other hand if the Select does not need the memo information they an execute faster
Lion Crest Software Services
Anthony L. Testi
President