[AccessD] Memo field corruption
df.waters at outlook.com
Sat Jan 26 11:10:14 CST 2019
In this page https://bytes.com/topic/access/answers/190112-query-memo-field-cuts-off-255-characters at the bottom it says this:
The reason for these limitations is that memo content is not actually
stored in the table. Only a pointer to its location on disk is. This
makes features like sorting and grouping _very_ inefficient because the
query has to use the pointer to go "get" the text, evaluate it, and then
apply the sorting and grouping.
So - if the data is already NOT stored in the table, why create another related table for memo fields?
I'd suggest trying to track down the source of this 'rule' before you go further with it. Maybe this was helpful for much older versions of Access for some reason?
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: January 26, 2019 10:27
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Memo field corruption
I think a lot of "expert" database developers suggest keeping the memo field
in a separate table using a 1:1 or 1:n relationship -- just in case.
I always include memo fields in the same table. I haven't heard of what you
described - have you seen that done somewhere?
When you include a memo field, do you include it in the table or do you
relate to a second table that stores just the memo field?
AccessD mailing list
AccessD at databaseadvisors.com
More information about the AccessD