corruption and memo fields

Is there a better way to deal with memo fields? I have a recurring issue
with this data field type corrupting a DB. Unfortuantely, the users need to
document narratives that exceed 255 characters so a text box is out of the
question.

Thanks

E

1. Find the root cause of the corruption issue. Sure memo fields are known to
corrupt more readily than, say, text fields, but something is causing the
problem. Maybe a network problem?

2. Use hyperlinks to text or Word documents is seaching in queries isn't a
issue.

3. Upsize to SQL Server or an Access Data Project.
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"E" wrote:

Is there a better way to deal with memo fields? I have a recurring issue
with this data field type corrupting a DB. Unfortuantely, the users need to
document narratives that exceed 255 characters so a text box is out of the
question.

Thanks

E

Thanks for your response,

1. Would the type of character typed by the user influence the corruption.
The users commonly use % @ # * (No I'm not swearing) in their narratives.

Also, the users often leave the DB open in the middle of typing one of these
narratives. Basically, they walk away with the cursor blinking in the input
box.

I'm grasping at straws.

2. not sure what you mean

3. I'd love to update to a more robust DB. That's not going to happen
unfortuantely.

Thanks again,

E

"Jerry Whittle" wrote:

1. Find the root cause of the corruption issue. Sure memo fields are known to
corrupt more readily than, say, text fields, but something is causing the
problem. Maybe a network problem?

2. Use hyperlinks to text or Word documents is seaching in queries isn't a
issue.

3. Upsize to SQL Server or an Access Data Project.
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"E" wrote:

Is there a better way to deal with memo fields? I have a recurring issue
with this data field type corrupting a DB. Unfortuantely, the users need to
document narratives that exceed 255 characters so a text box is out of the
question.

Thanks

E

No. Using non-text keyboard characters is not a factor.

I agree with Jerry that you need to identify the cause of the corruption and
deal with it. Work through this list of items:
Preventing corruption
at:
http://allenbrowne.com/ser-25.html

There will be something there that addresses your situation, e.g. machines
that do not have the service packs applied, or machines using WiFi, or a
machine with a bad network card.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"E" wrote in message
...
Thanks for your response,

1. Would the type of character typed by the user influence the
corruption.
The users commonly use % @ # * (No I'm not swearing) in their narratives.

Also, the users often leave the DB open in the middle of typing one of
these
narratives. Basically, they walk away with the cursor blinking in the
input
box.

I'm grasping at straws.

2. not sure what you mean

3. I'd love to update to a more robust DB. That's not going to happen
unfortuantely.

Thanks again,

E

"Jerry Whittle" wrote:

1. Find the root cause of the corruption issue. Sure memo fields are
known to
corrupt more readily than, say, text fields, but something is causing the
problem. Maybe a network problem?

2. Use hyperlinks to text or Word documents is seaching in queries isn't
a
issue.

3. Upsize to SQL Server or an Access Data Project.

"E" wrote:

Is there a better way to deal with memo fields? I have a recurring
issue
with this data field type corrupting a DB. Unfortuantely, the users
need to
document narratives that exceed 255 characters so a text box is out of
the
question.