I have not seen a difference in FMs or Ms in this regard.

In the early days the thinking was make the size in table as large as needed
based on the data. In other words, if a M field was going hold about 50 chars
and sometimes greatly exceed that, make it 50. The idea was to avoid "going
outside the table on table actions".


Then later many thought make single tables with a key and 1 single FM field
and link, contain the FM in its own table.


I have not seen any stability or performance differences in any method.

I have some odd behavior when pasting into FM from modern office (Word),
Paradox sometimes crashes.


On most of my newer (ha!) systems I store FM in word or wordpad files and
read/write them externally. Limitations, but seem to be more stable. I even
try to have that "field" just open wordpad and handle them externally. Does
not always work.




Steve Green <steve@oasistradingpost.com> wrote:
>
>yeah, I know.. avoid at all costs.. however, for this project, there are

>a few that I can't eliminate right now
>
>all are F240 in the tables, most are really several K in the memo file..

>all are problematic.. "formatted memo header" errors are common
>
>the actual content is basically a small Word or Wordpad doc.. a font, 
>some bullet points, usually some bold
>
>question.. from experience, if any, more stability if the base field in

>the table holds as much as possible, like the F240, or more stability if

>the base field in the table is just a small F10, or even F1? or does it

>not matter?
>
>
>-- 
>Steven Green
>Myrtle Beach, South Carolina USA
>
>http://www.OasisTradingPost.com
>
>Collectibles and Memorabilia
>Vintage Lego Sets and Parts
>- and Paradox support, too