recurring corruption issue

[Slez via AccessMonster.com]

I have a recurring corruption issue that appears to be stemming from a Memo
field in a table. I have done extensive searching about this topic and have
pretty much implemented all possible anti-corruption practices. The field is
not part of a link with another table. I have also used a text field in its
place and not experienced any problems, but the 255 characters just isn't
enough in some cases.

What's happening? The field "ScopeNotes" exists as a control on a form. It
seems that when users close the form while the focus is in the "ScopeNotes"
(Memo) field, it ends up showing as #Deleted in the field. Occasionally, it
corrupts to the point where tI get the "unrecognized database format..."
error. It has always been repaired by compacting, and we have never lost any
other data other than what's in this particular field.

I was thinking of 2 options:
1. Create a separate form with only that control on it, just to see if we
still get the corruption.
2. Creating a new table so many records in a Text field could be entered.

Any thoughts on a workaround for this?
Suggestions are appreciated!
Slez

--
Message posted via http://www.accessmonster.com

[Tony Toews [MVP]]

"Slez via AccessMonster.com" <u23064@uwewrote:

>What's happening? The field "ScopeNotes" exists as a control on a form. It
seems that when users close the form while the focus is in the "ScopeNotes"
(Memo) field, it ends up showing as #Deleted in the field.

Is that always or some times. How do your users close the form? By clicking on the
small X or a cmmand button? If a command button then by clicking on it the focus
gets changed to the command button from the field.

Are the users all using the same Jet SP? What I've done is use the various API calls
available and am checking the version number and date/time of a crucial dll,
msjetxx.dll, to ensure it matches what I have on my system. See the Verify
Appropriate Jet Service Pack is installed page at my website for more details
including sample code: www.granite.ab.ca\access\verifyjetsp.htm

>I was thinking of 2 options:
1. Create a separate form with only that control on it, just to see if we
still get the corruption.
2. Creating a new table so many records in a Text field could be entered.

I know that solution 2 is what one person did quite a while back. He concatenated
multiple text records into one memo field on the form and split it back out again to
the table.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[David W. Fenton]

"Slez via AccessMonster.com" <u23064@uwewrote in
news:771539bf47e76@uwe:

The field "ScopeNotes" exists as a control on a form. It
seems that when users close the form while the focus is in the
"ScopeNotes" (Memo) field, it ends up showing as #Deleted in the
field. Occasionally, it corrupts to the point where tI get the
"unrecognized database format..." error. It has always been
repaired by compacting, and we have never lost any other data
other than what's in this particular field.

Is the textbox bound to the memo field? Try making it unbound, and
load the memo values in the form's OnCurrent event, and write them
out in the control's AfterUpdate. That event should fire when the
form is closed (or you could force it if you're using a command
button, which is probably a better choice).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Slez via AccessMonster.com]

I removed the closing "X" so users are forced to close the form using the
command button, and also have found we are in need of service packs on some
systems. Our IT is working on that. Hopefully that will resolve the issue,
but I do have one additional question:

The form in question has the ScopeNotes control and a few other controls from
the parent records and there is a subform with the child records. All
controls are in the detail section of the form. I don't think the parent
records are required to be in the header section, but thought I'd throw this
out there if you felt it could be a contributing factor to the corruption
issue. Any thoughts on this?

Thanks for all your help!
Slez
Allen Browne wrote:

>Okay, most of that is fairly standard.

Using the Windows Explorer (i.e. My Computer) in the machine where the
problem occurs, locate msaccess.exe, typically in:
C:\Program Files\Microsoft Office\Office
Right-click and choose properties.
On the Version tab, the version number should be:
10.0.6501.0
Anything less, they need a service pack from:
http://support.microsoft.com/sp/

Then locate msjet40.dll, typicially in:
C:\Windows\System32
The version should be at least:
4.0.8618.0
Depending on their version of Windows, the minor version may begin with a 9,
but if it is less than 8, they need the JET service pack (last item under
Developer Tools on the same link above.)

What I do is to display this version stuff on the Help About screen in my
apps, so a user can just read it to you over the phone. Details in:
Splash screen with version information
at:
http://allenbrowne.com/ser-53.html

Hopefully the command-button-only exit solves this for you. Arvin suggested
an unbound box; you would need to use the command-button-only exit for that
approach also.

>Thanks for the reply!

[quoted text clipped - 68 lines]

>>>Suggestions are appreciated!
Slez

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200708/1

[Allen Browne]

So you have a main form (with ScopeNotes and some other controls) and a
subform (bound to a related table.)

You say that all controls are in the Detail section of their respective form
(i.e. no bound controls are in the Form Header or Form Footer sections of
any form.) That's fine. Having them in the Detail section will not
contribute to the problem.

Both the JET 4 and Office service packs are crucial, so hopefully this will
fix your corruption issues.

--
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.

"Slez via AccessMonster.com" <u23064@uwewrote in message
news:77566df9ec882@uwe...

>I removed the closing "X" so users are forced to close the form using the
command button, and also have found we are in need of service packs on
some
systems. Our IT is working on that. Hopefully that will resolve the
issue,
but I do have one additional question:

The form in question has the ScopeNotes control and a few other controls
from
the parent records and there is a subform with the child records. All
controls are in the detail section of the form. I don't think the parent
records are required to be in the header section, but thought I'd throw
this
out there if you felt it could be a contributing factor to the corruption
issue. Any thoughts on this?

Thanks for all your help!
Slez
Allen Browne wrote:

>>Okay, most of that is fairly standard.

Using the Windows Explorer (i.e. My Computer) in the machine where the
problem occurs, locate msaccess.exe, typically in:
C:\Program Files\Microsoft Office\Office
Right-click and choose properties.
On the Version tab, the version number should be:
10.0.6501.0
Anything less, they need a service pack from:
http://support.microsoft.com/sp/

Then locate msjet40.dll, typicially in:
C:\Windows\System32
The version should be at least:
4.0.8618.0
Depending on their version of Windows, the minor version may begin with a
9,
but if it is less than 8, they need the JET service pack (last item under
Developer Tools on the same link above.)

What I do is to display this version stuff on the Help About screen in my
apps, so a user can just read it to you over the phone. Details in:
Splash screen with version information
at:
http://allenbrowne.com/ser-53.html

Hopefully the command-button-only exit solves this for you. Arvin
suggested
an unbound box; you would need to use the command-button-only exit for
that
approach also.

>>Thanks for the reply!

[quoted text clipped - 68 lines]

>>>>Suggestions are appreciated!
Slez