Corrupt memo fields in Access 97? 
Author Message
 Corrupt memo fields in Access 97?

I have read several posts saying that they have seen corruption relating to
memo fields in A97.  As a general matter, are memo fields stable enough to
rely upon in an application, or is it better to use text fields instead?


Wed, 06 Aug 2003 00:53:35 GMT  
 Corrupt memo fields in Access 97?
In my experience, the memo fields are as unstable
as the local network.  What I mean by that is if
you used linked tables to get to your data on an
Access back end and your network is prone to
sporadic disconnects, then you WILL get corrupted
memo fields along with other Long value
corruptions.  The work arounds are as you
mentioned, using text fields, OR making your
desktop front end application disconnected (no
linked tables) and control the adding, deleting
and editing of records to the server, through
code. The problem with the text fields are
obvious. You are limited on the length of data.
You can concantenate several together if
necessary, but how many do you add to your tables?
It will always be at least one less than SOMEONE
needs.

message

...
Quote:
> I have read several posts saying that they have

seen corruption relating to
Quote:
> memo fields in A97.  As a general matter, are

memo fields stable enough to
Quote:
> rely upon in an application, or is it better to

use text fields instead?


Wed, 06 Aug 2003 02:41:02 GMT  
 Corrupt memo fields in Access 97?
Rick,

So if I use unbound fields in my form for initial data entry for a memo
field, then write it out to the server when they click the save button I
should be relatively safe?  I suppose that would mean if they chose to edit
a record I would need to pull all the fields from the table on the server
into unbound fields on a form for editing, lock the record, then write the
changes back to the table when the user saves the changes.  Does this sound
workable to you?

Bill


Quote:
> In my experience, the memo fields are as unstable
> as the local network.  What I mean by that is if
> you used linked tables to get to your data on an
> Access back end and your network is prone to
> sporadic disconnects, then you WILL get corrupted
> memo fields along with other Long value
> corruptions.  The work arounds are as you
> mentioned, using text fields, OR making your
> desktop front end application disconnected (no
> linked tables) and control the adding, deleting
> and editing of records to the server, through
> code. The problem with the text fields are
> obvious. You are limited on the length of data.
> You can concantenate several together if
> necessary, but how many do you add to your tables?
> It will always be at least one less than SOMEONE
> needs.

> message

> ...
> > I have read several posts saying that they have
> seen corruption relating to
> > memo fields in A97.  As a general matter, are
> memo fields stable enough to
> > rely upon in an application, or is it better to
> use text fields instead?



Wed, 06 Aug 2003 03:34:53 GMT  
 Corrupt memo fields in Access 97?
Exactly what I do at one of my customers sites.
You can even carry it further by setting the tag
property to the field name on all the controls
that you want the user to be able to edit and then
loop through all the controls looking for the tag
property.  If it is null, then you don't save that
data, but if it isn't null, you have the field
name to use in your code.  I take it a little
further in the sense that when a user opens the
app, I read the users login from an API call and
then only pull in data to their local drive, that
they are responsible for (if applicable in your
situation).  This makes their desktop app run a
lot faster without all the extra data overhead.


message

...

Quote:
> Rick,

> So if I use unbound fields in my form for

initial data entry for a memo
Quote:
> field, then write it out to the server when they

click the save button I
Quote:
> should be relatively safe?  I suppose that would

mean if they chose to edit
Quote:
> a record I would need to pull all the fields

from the table on the server
Quote:
> into unbound fields on a form for editing, lock

the record, then write the
Quote:
> changes back to the table when the user saves

the changes.  Does this sound
Quote:
> workable to you?

> Bill


message

> > In my experience, the memo fields are as
unstable
> > as the local network.  What I mean by that is
if
> > you used linked tables to get to your data on
an
> > Access back end and your network is prone to
> > sporadic disconnects, then you WILL get
corrupted
> > memo fields along with other Long value
> > corruptions.  The work arounds are as you
> > mentioned, using text fields, OR making your
> > desktop front end application disconnected (no
> > linked tables) and control the adding,
deleting
> > and editing of records to the server, through
> > code. The problem with the text fields are
> > obvious. You are limited on the length of
data.
> > You can concantenate several together if
> > necessary, but how many do you add to your
tables?
> > It will always be at least one less than
SOMEONE
> > needs.

in
> > message


- Show quoted text -

Quote:
> > ...
> > > I have read several posts saying that they
have
> > seen corruption relating to
> > > memo fields in A97.  As a general matter,
are
> > memo fields stable enough to
> > > rely upon in an application, or is it better
to
> > use text fields instead?



Wed, 06 Aug 2003 04:26:05 GMT  
 Corrupt memo fields in Access 97?
Rick,

Thanks a lot for the help.

Bill


Quote:
> Exactly what I do at one of my customers sites.
> You can even carry it further by setting the tag
> property to the field name on all the controls
> that you want the user to be able to edit and then
> loop through all the controls looking for the tag
> property.  If it is null, then you don't save that
> data, but if it isn't null, you have the field
> name to use in your code.  I take it a little
> further in the sense that when a user opens the
> app, I read the users login from an API call and
> then only pull in data to their local drive, that
> they are responsible for (if applicable in your
> situation).  This makes their desktop app run a
> lot faster without all the extra data overhead.


> message

> ...
> > Rick,

> > So if I use unbound fields in my form for
> initial data entry for a memo
> > field, then write it out to the server when they
> click the save button I
> > should be relatively safe?  I suppose that would
> mean if they chose to edit
> > a record I would need to pull all the fields
> from the table on the server
> > into unbound fields on a form for editing, lock
> the record, then write the
> > changes back to the table when the user saves
> the changes.  Does this sound
> > workable to you?

> > Bill


> message

> > > In my experience, the memo fields are as
> unstable
> > > as the local network.  What I mean by that is
> if
> > > you used linked tables to get to your data on
> an
> > > Access back end and your network is prone to
> > > sporadic disconnects, then you WILL get
> corrupted
> > > memo fields along with other Long value
> > > corruptions.  The work arounds are as you
> > > mentioned, using text fields, OR making your
> > > desktop front end application disconnected (no
> > > linked tables) and control the adding,
> deleting
> > > and editing of records to the server, through
> > > code. The problem with the text fields are
> > > obvious. You are limited on the length of
> data.
> > > You can concantenate several together if
> > > necessary, but how many do you add to your
> tables?
> > > It will always be at least one less than
> SOMEONE
> > > needs.

> in
> > > message


> > > ...
> > > > I have read several posts saying that they
> have
> > > seen corruption relating to
> > > > memo fields in A97.  As a general matter,
> are
> > > memo fields stable enough to
> > > > rely upon in an application, or is it better
> to
> > > use text fields instead?



Wed, 06 Aug 2003 05:02:56 GMT  
 Corrupt memo fields in Access 97?

Quote:

>I have read several posts saying that they have seen corruption relating to
>memo fields in A97.  As a general matter, are memo fields stable enough to
>rely upon in an application, or is it better to use text fields instead?

Apparently either SR-1 or SR-2 fixed the vast majority of corruptions
caused by memo fields.  I've lightly used them for years with no
problems.

One person I know created a system where he had a separate table with
a 255 char text fields.  He then divided up the memo field on the form
in 255 byte chunks read and wrote to this table as required.

Tony

----
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm



Thu, 07 Aug 2003 10:49:02 GMT  
 Corrupt memo fields in Access 97?
Tony and Rick,

Thanks for your thoughts on this.

Bill


Quote:
> I have read several posts saying that they have seen corruption relating
to
> memo fields in A97.  As a general matter, are memo fields stable enough to
> rely upon in an application, or is it better to use text fields instead?



Thu, 07 Aug 2003 11:02:49 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Accessing empty/null Memo Fields in a Access 97

2. How to FULL JUSTIFY TEXT of a MEMO Field in Access 97 reports or VBA

3. ADO Update (using VB) of Memo fields in Access 97 DB

4. Access 97 memo field

5. Memo Field Corrupting.

6. Corrupted dBase memo field

7. Corrupted Access97 Database because of memo Field?

8. corrupted index in Access 97

9. Corrupt Access 97 VBA Project?

10. Corrupted Access 97 table - can it be salvaged?

11. Corrupted Databases in Access 97

12. MS Access 97 copyobject method corrupting table object

 

 
Powered by phpBB® Forum Software