at wit's end about corrupted records in Access 2k table!

[Lee Rouse]

Hello all,

This is going to be a rather lengthy "question".

I have an Access 2k database, separated front end/back end. Front end
copies are on about 30 workstations and used frequently during the
work day. The backend has a table called CLIENTS with approximately
6000 client records. Changes to data in the table are made via a
frontend db Form which has CLIENTS as its record source.

During the past week, approximately 6 records have become corrupted in
this table. The table itself can still be opened and closed. In most
cases, data can be updated without a problem.

But at least once a day, a user will be updating a record, and all
fields associated with that record become corrupted. This may happen
when the user is actually entering data, or may happen if she has
entered data and then left the record (form)open. There has typically
been no warning or error message.

I've opened the backend db and found these corrupted records in the
CLIENTS table. They are obviously corrupted. When I try to delete them
I get the error message about "search key was not found". If I copy
the backend database onto my local hard drive, I've had pretty good
sucess deleting these corrupt records.

I did a lot of searching for answers, including Google groups and the
MS Knowledge base. So far I've tried the following:

First, I uddated the msjet40.dll file on all computers

Next, I used a MakeTable query, to deposit all the good records into a
new table, deleted the original CLIENTS table, and renamed the new one
CLIENTS.

I then created a new blank database, and imported all the objects from
the old database, renamed the new database to the old name, deleted
the old database, and copied the new one back onto the server.

Everything seemed fine for a day. Then yesterday I opened the database
and received an error message that the backend database was in an
unrecognizable format or had been damaged. When given the option to
try and repair it, I clicked "Yes". Compact/repair started. Abouthalf
way through the process, Access stopped responding entirely.

I then tried using Jetcomp.exe to repair. That also hung up about 1/2
way through.

Unsure what else to do, I restored the backup copy of the database
that was saved last night on the server.

This morning everything was working fine until I was making changes in
record. When I clicked to close the form, I got a "write conflict"
message that another user had made changes in the records since I
opened it- did I want to save changes, copy to clipboard, or not save
changes. If I clicked NO, the form closed fine. I could reopen and
access the record. If I clicked YES, the record became corrupted. I
purposely chose this particular record because it was a very old one
that I knew noone else would be working on.

So the bottom line is that I still have a sick database. Our agency
depends on this database daily to track referrals, evaluation, and
treatment for special needs children. It would be disastrous to lose
it, but I am absolutley out of ideas as to what I should do next. By
the way, there is not a memo field in this table.

If you have any suggestions beyond what I've tried, please respond.

Lee

[Pavel Romashkin]

Re: at wit's end about corrupted records in Access 2k table!

I sure hope someone else pitches in with more advice. What I would try:
Restore the BE DB from the backup and try compact/reparing it before you
get corruption.
Try to run it locally (not over LAN) via the front end - does the
corruption occur anyway? If not, it must be a poor LAN connection. Did
they "fix" the network recently?
If nothing else works, I would try to back up this database and not use
it for editing records - only for retrieving old records, and put new
records into an empty table with identical structure.

Good luck,
Pavel

Lee Rouse wrote:[color=blue]
>
> Hello all,
>
> This is going to be a rather lengthy "question".
>
> I have an Access 2k database, separated front end/back end. Front end
> copies are on about 30 workstations and used frequently during the
> work day. The backend has a table called CLIENTS with approximately
> 6000 client records. Changes to data in the table are made via a
> frontend db Form which has CLIENTS as its record source.
>
> During the past week, approximately 6 records have become corrupted in
> this table. The table itself can still be opened and closed. In most
> cases, data can be updated without a problem.
>
> But at least once a day, a user will be updating a record, and all
> fields associated with that record become corrupted. This may happen
> when the user is actually entering data, or may happen if she has
> entered data and then left the record (form)open. There has typically
> been no warning or error message.
>
> I've opened the backend db and found these corrupted records in the
> CLIENTS table. They are obviously corrupted. When I try to delete them
> I get the error message about "search key was not found". If I copy
> the backend database onto my local hard drive, I've had pretty good
> sucess deleting these corrupt records.
>
> I did a lot of searching for answers, including Google groups and the
> MS Knowledge base. So far I've tried the following:
>
> First, I uddated the msjet40.dll file on all computers
>
> Next, I used a MakeTable query, to deposit all the good records into a
> new table, deleted the original CLIENTS table, and renamed the new one
> CLIENTS.
>
> I then created a new blank database, and imported all the objects from
> the old database, renamed the new database to the old name, deleted
> the old database, and copied the new one back onto the server.
>
> Everything seemed fine for a day. Then yesterday I opened the database
> and received an error message that the backend database was in an
> unrecognizable format or had been damaged. When given the option to
> try and repair it, I clicked "Yes". Compact/repair started. Abouthalf
> way through the process, Access stopped responding entirely.
>
> I then tried using Jetcomp.exe to repair. That also hung up about 1/2
> way through.
>
> Unsure what else to do, I restored the backup copy of the database
> that was saved last night on the server.
>
> This morning everything was working fine until I was making changes in
> record. When I clicked to close the form, I got a "write conflict"
> message that another user had made changes in the records since I
> opened it- did I want to save changes, copy to clipboard, or not save
> changes. If I clicked NO, the form closed fine. I could reopen and
> access the record. If I clicked YES, the record became corrupted. I
> purposely chose this particular record because it was a very old one
> that I knew noone else would be working on.
>
> So the bottom line is that I still have a sick database. Our agency
> depends on this database daily to track referrals, evaluation, and
> treatment for special needs children. It would be disastrous to lose
> it, but I am absolutley out of ideas as to what I should do next. By
> the way, there is not a memo field in this table.
>
> If you have any suggestions beyond what I've tried, please respond.
>
> Lee[/color]

[David W. Fenton]

Re: at wit's end about corrupted records in Access 2k table!

leemodeler@yaho o.com (Lee Rouse) wrote in
news:8135f01d.0 402131239.1728f f5@posting.goog le.com:

[]
[color=blue]
> During the past week, approximately 6 records have become
> corrupted in this table. The table itself can still be opened and
> closed. In most cases, data can be updated without a problem.
>
> But at least once a day, a user will be updating a record, and all
> fields associated with that record become corrupted. This may
> happen when the user is actually entering data, or may happen if
> she has entered data and then left the record (form)open. There
> has typically been no warning or error message.
>
> I've opened the backend db and found these corrupted records in
> the CLIENTS table. They are obviously corrupted. When I try to
> delete them I get the error message about "search key was not
> found". If I copy the backend database onto my local hard drive,
> I've had pretty good sucess deleting these corrupt records.[/color]

I've seen the SEARCH KEY NOT FOUND error in cases where I was using
the wrong security file, but only before Jet 4 SP 6 (see below).
[color=blue]
> I did a lot of searching for answers, including Google groups and
> the MS Knowledge base. So far I've tried the following:
>
> First, I uddated the msjet40.dll file on all computers[/color]

Well, you can't really do that by itself.

Update at least to Jet 4 Service Pack 6. Don't consider SP7, but SP8
is the latest. The most widespread Jet 4 problems are fixed by SP6
(all my A2K clients are on it).

And A2K itself should be Service Release 1a or later (Office SR2 and
above implements that Draconian Outlook security patch, which
prevents the saving or opening of almost all attachmets, so you may
not want to apply it; I never apply anything Office 2K SR1a).
[color=blue]
> Next, I used a MakeTable query, to deposit all the good records
> into a new table, deleted the original CLIENTS table, and renamed
> the new one CLIENTS.
>
> I then created a new blank database, and imported all the objects
> from the old database, renamed the new database to the old name,
> deleted the old database, and copied the new one back onto the
> server.
>
> Everything seemed fine for a day. Then yesterday I opened the
> database and received an error message that the backend database
> was in an unrecognizable format or had been damaged. When given
> the option to try and repair it, I clicked "Yes". Compact/repair
> started. Abouthalf way through the process, Access stopped
> responding entirely.[/color]

Until all workstations are at SR1a+ and Jet SP 4 SP6 or SP8, don't
waste your time with anything else.
[color=blue]
> I then tried using Jetcomp.exe to repair. That also hung up about
> 1/2 way through.
>
> Unsure what else to do, I restored the backup copy of the database
> that was saved last night on the server.
>
> This morning everything was working fine until I was making
> changes in record. When I clicked to close the form, I got a
> "write conflict" message that another user had made changes in the
> records since I opened it- did I want to save changes, copy to
> clipboard, or not save changes. If I clicked NO, the form closed
> fine. I could reopen and access the record. If I clicked YES, the
> record became corrupted. I purposely chose this particular record
> because it was a very old one that I knew noone else would be
> working on.
>
> So the bottom line is that I still have a sick database. . . .[/color]

I think you should recreate the database, and not by an import.

I would import table structures only (no data), then append the data
from the tables in corrupt MDB into the fresh one.
[color=blue]
> . . . Our
> agency depends on this database daily to track referrals,
> evaluation, and treatment for special needs children. It would be
> disastrous to lose it, but I am absolutley out of ideas as to what
> I should do next. By the way, there is not a memo field in this
> table.[/color]

Does the table that is corrupting have memo fields?

If so, you should seriously consider not using a bound field for all
the memo fields. The way you implement that is:

1. remove the ControlSource of the text fields bound to the memo
fields.

2. in the OnCurrent event of each record, copy the data from the
memo fields in the form's recordsource into the textboxes for those
memos. You'll want to make sure your textboxes do *not* have the
same names as the underlying fields, or you'll run into problems.

3. in the memo's AfterUpdate event, check the value of the memo
textboxes against the value of the field in the underlying
recordsource, and if it's changed, update it.

It would look something like this:

OnCurrent:

Me!txtMemo = Me!Memo

AfterUpdate:

If Nz(Me!txtMemo) <> Nz(Me!Memo) Then
Me!Memo = Me!txtMemo
End If

You may want to move the updating the of the underlying field to the
Form's AfterUpdate event. That would have the advantage of keeping
the record dirty for memo changes the shortest period of time
possible.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Tony Toews]

Re: at wit's end about corrupted records in Access 2k table!

leemodeler@yaho o.com (Lee Rouse) wrote:
[color=blue]
>This is going to be a rather lengthy "question".[/color]

We much prefer lengthy questions to very short questions.
[color=blue]
>During the past week,[/color]

What has changed a week ago? New server? New computer added to network? Hardware
change? New SP on a computer?

David has already given you some excellent advice. But I'll add a couple of more
things.

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 tips page at my website for more details including sample
code: Verify Appropriate Jet Service Pack is installed
www.granite.ab.ca\access\verifyjetsp.htm

Also see the Access Corruption FAQ at my website.

The KB article which David mentions can be found at
ACC2000: "Search Key Was Not Found in Any Record" Error Message During Compact or
Save http://support.microsoft.com/?id=301474
[color=blue]
>This morning everything was working fine until I was making changes in
>record. When I clicked to close the form, I got a "write conflict"
>message that another user had made changes in the records since I
>opened it- did I want to save changes, copy to clipboard, or not save
>changes. If I clicked NO, the form closed fine. I could reopen and
>access the record. If I clicked YES, the record became corrupted. I
>purposely chose this particular record because it was a very old one
>that I knew noone else would be working on.[/color]

Hmm, now this is interesting. But I have no good answer.

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

[David W. Fenton]

Re: at wit's end about corrupted records in Access 2k table!

Tony Toews <ttoews@teluspl anet.net> wrote in
news:l1mq2017jo 9eldqeue6u155sl 7bsokjc9m@4ax.c om:
[color=blue]
> leemodeler@yaho o.com (Lee Rouse) wrote:[/color]
[color=blue][color=green]
>>This morning everything was working fine until I was making
>>changes in record. When I clicked to close the form, I got a
>>"write conflict" message that another user had made changes in the
>>records since I opened it- did I want to save changes, copy to
>>clipboard, or not save changes. If I clicked NO, the form closed
>>fine. I could reopen and access the record. If I clicked YES, the
>>record became corrupted. I purposely chose this particular record
>>because it was a very old one that I knew noone else would be
>>working on.[/color]
>
> Hmm, now this is interesting. But I have no good answer.[/color]

That sounds like the kind of crap you get when you have something
other than Jet 4 SP6 and SR1a.

The original release of A2K was terrible, and it took MS about 2
years to get it into a state that was reliable.

Since SP6 and SR1a, though, A2K runs just fine in a production
environment.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Randy Harris]

Re: at wit's end about corrupted records in Access 2k table!

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
news:Xns948EC87 493F25dfentonbw aynetinvali@24. 168.128.86...[color=blue]
> Tony Toews <ttoews@teluspl anet.net> wrote in
> news:l1mq2017jo 9eldqeue6u155sl 7bsokjc9m@4ax.c om:
>[color=green]
> > leemodeler@yaho o.com (Lee Rouse) wrote:[/color]
>[color=green][color=darkred]
> >>This morning everything was working fine until I was making
> >>changes in record. When I clicked to close the form, I got a
> >>"write conflict" message that another user had made changes in the
> >>records since I opened it- did I want to save changes, copy to
> >>clipboard, or not save changes. If I clicked NO, the form closed
> >>fine. I could reopen and access the record. If I clicked YES, the
> >>record became corrupted. I purposely chose this particular record
> >>because it was a very old one that I knew noone else would be
> >>working on.[/color]
> >
> > Hmm, now this is interesting. But I have no good answer.[/color]
>
> That sounds like the kind of crap you get when you have something
> other than Jet 4 SP6 and SR1a.
>
> The original release of A2K was terrible, and it took MS about 2
> years to get it into a state that was reliable.
>
> Since SP6 and SR1a, though, A2K runs just fine in a production
> environment.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

David, would you happen to know how I can tell what my current Jet service
pack level is?

[Lee]

Re: at wit's end about corrupted records in Access 2k table!

All the computers in our agency have been upgraded to Jet SP8. That was the
first thing I did.

Lee


"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
news:Xns948EC87 493F25dfentonbw aynetinvali@24. 168.128.86...[color=blue]
> Tony Toews <ttoews@teluspl anet.net> wrote in
> news:l1mq2017jo 9eldqeue6u155sl 7bsokjc9m@4ax.c om:
>[color=green]
> > leemodeler@yaho o.com (Lee Rouse) wrote:[/color]
>[color=green][color=darkred]
> >>This morning everything was working fine until I was making
> >>changes in record. When I clicked to close the form, I got a
> >>"write conflict" message that another user had made changes in the
> >>records since I opened it- did I want to save changes, copy to
> >>clipboard, or not save changes. If I clicked NO, the form closed
> >>fine. I could reopen and access the record. If I clicked YES, the
> >>record became corrupted. I purposely chose this particular record
> >>because it was a very old one that I knew noone else would be
> >>working on.[/color]
> >
> > Hmm, now this is interesting. But I have no good answer.[/color]
>
> That sounds like the kind of crap you get when you have something
> other than Jet 4 SP6 and SR1a.
>
> The original release of A2K was terrible, and it took MS about 2
> years to get it into a state that was reliable.
>
> Since SP6 and SR1a, though, A2K runs just fine in a production
> environment.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

[Lee]

Re: at wit's end about corrupted records in Access 2k table!

[color=blue]
> David, would you happen to know how I can tell what my current Jet service
> pack level is?
>
>
>
> I can answer that one. Try[/color]

http://support.microsoft.com/default.aspx?kbid=239114

Lee
[color=blue]
>[/color]

[David W. Fenton]

Re: at wit's end about corrupted records in Access 2k table!

"Lee" <lrouse2REMOVEM E@cox.net> wrote in
news:zveXb.4962 $Yj.888@lakerea d02:
[color=blue]
> All the computers in our agency have been upgraded to Jet SP8.
> That was the first thing I did.[/color]

Absolutely 100% of them?

The reason I asked is that I thought I did this at one of my
clients, and then corruption returned. I then examined the PCs and
discovered that I'd missed ONE PC. And that one PC was causing the
problem. When it was patched, the corruption went away permanently.

And it's not just the Jet service pack that matters -- you have to
have something other than the shipping version of Access 2K.

I use code in my A2K apps that logs the version of Jet and the
version of MSAccess.exe in use when users log in so that if
corruption recurs, I can check the log to see which machines are the
likely culprits. It's too easy for machines to end up reverted to
earlier versions after re-installs.

The code I use for this logging was based on the code Tony has
already recommended to you on his website.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Allen Browne]

Re: at wit's end about corrupted records in Access 2k table!

"Randy Harris" <randy@SpamFree .com> asked in message
news:eheXb.2277 $t16.1860883@ne wssvr28.news.pr odigy.com...[color=blue]
>
> David, would you happen to know how I can tell what my current Jet service
> pack level is?[/color]

Randy, this is such an important issue, that we place a screen in every app
where the user can easily tell us their version of Access and JET and the
service packs applied.

We use an Access form for a Help | About screen.
The text box for the Access version has Control Source:
=fGetProductVer sion(SysCmd(9) & "msaccess.e xe")
and the one for the JET service pack:
=fGetProductVer sion(fReturnSys Dir() & "\msjet40.d ll")

Copy the functions from:

http://www.mvps.org/access/api/api0065.htm

http://www.mvps.org/access/api/api0010.htm

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

[Tony Toews]

Re: at wit's end about corrupted records in Access 2k table!

"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote:
[color=blue][color=green]
>> All the computers in our agency have been upgraded to Jet SP8.
>> That was the first thing I did.[/color]
>
>Absolutely 100% of them?
>
>The reason I asked is that I thought I did this at one of my
>clients, and then corruption returned. I then examined the PCs and
>discovered that I'd missed ONE PC. And that one PC was causing the
>problem. When it was patched, the corruption went away permanently.[/color]

Ah, another corroborating posting that mixing Jet versions doe lead to corruptions.
[color=blue]
>I use code in my A2K apps that logs the version of Jet and the
>version of MSAccess.exe in use when users log in so that if
>corruption recurs, I can check the log to see which machines are the
>likely culprits.[/color]

Whereas I pop up a warning message. But same difference.
[color=blue]
>It's too easy for machines to end up reverted to
>earlier versions after re-installs.[/color]

Or a new computer is attached to the network. Or someone brings a laptop from home
or wherever. Or ....

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

[Salad]

Re: at wit's end about corrupted records in Access 2k table!

Tony Toews wrote:
[color=blue][color=green]
> >This morning everything was working fine until I was making changes in
> >record. When I clicked to close the form, I got a "write conflict"
> >message that another user had made changes in the records since I
> >opened it- did I want to save changes, copy to clipboard, or not save
> >changes. If I clicked NO, the form closed fine. I could reopen and
> >access the record. If I clicked YES, the record became corrupted. I
> >purposely chose this particular record because it was a very old one
> >that I knew noone else would be working on.[/color]
>
> Hmm, now this is interesting. But I have no good answer.[/color]

This is something Lee can check out. In the exit command code I'd pur the following
Private Sub CommandExit_Cli ck
On Error Goto Err_CommandExit _Click

If Me.Dirty Then Docmd.RunComman d acCmdSaveRecord
Docmd.Close acForm,"This FormName",acSav eNo

Err_CommandExit _Click
Exit Sub

Err_CommandExit _Click
If Err.number <> 2501 then msgbox err.description
resume Exit_CommandExi t_Click

end sub

[Lee]

Re: at wit's end about corrupted records in Access 2k table!

Let me give you a little more detail on this. The "write conflict" was
triggered on exiting my main input form, but only after I added an "after
update" event to one of the fields. This event was very basic (reflecting my
level of expertise!). It simply put the same data I had typed in "FIELD A"
into "FIELD B" , after the first field was updated. Note that this code was
added yesterday, and was not a long standing part of the form.

When I removed the code, and manually typed the information first in field
A, then field B, the "write conflict" did not occur.

Having a limited understanding of coding, I don't understand the CommandExit
code. Can you explain what this does?

I will not have time today to apply the suggestions everyone has offered in
their responses, but hope to get to the office tomorrow afternoon. Please
"stay tuned".

Thanks,

Lee


"Salad" <oil@vinegar.co m> wrote in message
news:402DE767.7 E3B11BA@vinegar .com...[color=blue]
> Tony Toews wrote:
>[color=green][color=darkred]
> > >This morning everything was working fine until I was making changes in
> > >record. When I clicked to close the form, I got a "write conflict"
> > >message that another user had made changes in the records since I
> > >opened it- did I want to save changes, copy to clipboard, or not save
> > >changes. If I clicked NO, the form closed fine. I could reopen and
> > >access the record. If I clicked YES, the record became corrupted. I
> > >purposely chose this particular record because it was a very old one
> > >that I knew noone else would be working on.[/color]
> >
> > Hmm, now this is interesting. But I have no good answer.[/color]
>
> This is something Lee can check out. In the exit command code I'd pur the[/color]
following[color=blue]
> Private Sub CommandExit_Cli ck
> On Error Goto Err_CommandExit _Click
>
> If Me.Dirty Then Docmd.RunComman d acCmdSaveRecord
> Docmd.Close acForm,"This FormName",acSav eNo
>
> Err_CommandExit _Click
> Exit Sub
>
> Err_CommandExit _Click
> If Err.number <> 2501 then msgbox err.description
> resume Exit_CommandExi t_Click
>
> end sub
>[/color]

[Lee]

Re: at wit's end about corrupted records in Access 2k table!

I have thought of one software update that was made on several workstations
prior to my current problem. Several, but not all, workstations have had
Novell client software updated- from Client 32 to Client 34. But I do not
believe that the corrupted files are specific to those machines.....

Lee



"Lee" <lrouse2REMOVEM E@cox.net> wrote in message
news:E%nXb.6445 $Yj.5843@lakere ad02...[color=blue]
> Let me give you a little more detail on this. The "write conflict" was
> triggered on exiting my main input form, but only after I added an "after
> update" event to one of the fields. This event was very basic (reflecting[/color]
my[color=blue]
> level of expertise!). It simply put the same data I had typed in "FIELD A"
> into "FIELD B" , after the first field was updated. Note that this code[/color]
was[color=blue]
> added yesterday, and was not a long standing part of the form.
>
> When I removed the code, and manually typed the information first in field
> A, then field B, the "write conflict" did not occur.
>
> Having a limited understanding of coding, I don't understand the[/color]
CommandExit[color=blue]
> code. Can you explain what this does?
>
> I will not have time today to apply the suggestions everyone has offered[/color]
in[color=blue]
> their responses, but hope to get to the office tomorrow afternoon. Please
> "stay tuned".
>
> Thanks,
>
> Lee
>
>
> "Salad" <oil@vinegar.co m> wrote in message
> news:402DE767.7 E3B11BA@vinegar .com...[color=green]
> > Tony Toews wrote:
> >[color=darkred]
> > > >This morning everything was working fine until I was making changes[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > >record. When I clicked to close the form, I got a "write conflict"
> > > >message that another user had made changes in the records since I
> > > >opened it- did I want to save changes, copy to clipboard, or not save
> > > >changes. If I clicked NO, the form closed fine. I could reopen and
> > > >access the record. If I clicked YES, the record became corrupted. I
> > > >purposely chose this particular record because it was a very old one
> > > >that I knew noone else would be working on.
> > >
> > > Hmm, now this is interesting. But I have no good answer.[/color]
> >
> > This is something Lee can check out. In the exit command code I'd pur[/color][/color]
the[color=blue]
> following[color=green]
> > Private Sub CommandExit_Cli ck
> > On Error Goto Err_CommandExit _Click
> >
> > If Me.Dirty Then Docmd.RunComman d acCmdSaveRecord
> > Docmd.Close acForm,"This FormName",acSav eNo
> >
> > Err_CommandExit _Click
> > Exit Sub
> >
> > Err_CommandExit _Click
> > If Err.number <> 2501 then msgbox err.description
> > resume Exit_CommandExi t_Click
> >
> > end sub
> >[/color]
>
>[/color]

[David W. Fenton]

Re: at wit's end about corrupted records in Access 2k table!

Tony Toews <ttoews@teluspl anet.net> wrote in
news:3gbr20lkbk gj0g4lj9t3vdsfe an1ik06li@4ax.c om:
[color=blue]
> "David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote:
>[color=green][color=darkred]
>>> All the computers in our agency have been upgraded to Jet SP8.
>>> That was the first thing I did.[/color]
>>
>>Absolutely 100% of them?
>>
>>The reason I asked is that I thought I did this at one of my
>>clients, and then corruption returned. I then examined the PCs and
>>discovered that I'd missed ONE PC. And that one PC was causing the
>>problem. When it was patched, the corruption went away
>>permanently .[/color]
>
> Ah, another corroborating posting that mixing Jet versions doe
> lead to corruptions.[/color]

I'm not sure if it's the mixing, or the particular substandard Jet
version (pre-SP6) on that one PC that is the problem.

And I also know that you can have Jet 4 SP6 and still have problems
if Access is not SR1a or higher.

So, I don't think it's the mixing so much as it is that you have to
reach a certain version level of both Jet and Access before you
eliminate the problems that tend to lead to corruption.
[color=blue][color=green]
>>I use code in my A2K apps that logs the version of Jet and the
>>version of MSAccess.exe in use when users log in so that if
>>corruption recurs, I can check the log to see which machines are
>>the likely culprits.[/color]
>
> Whereas I pop up a warning message. But same difference.[/color]

Well, it's not something the users can fix, and I am of the "if it
ain't broke don't fix it" school, so I don't bother with fixing it
until there's a problem to be addressed.
[color=blue][color=green]
>>It's too easy for machines to end up reverted to
>>earlier versions after re-installs.[/color]
>
> Or a new computer is attached to the network. Or someone brings a
> laptop from home or wherever. Or ....[/color]

Yep. Fortunately neither of those things happens in the environments
I'm working with without somebody following my 7 pages of
illustrated instructions on how to patch a PC and install the
program.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc