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]

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:

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

[David W. Fenton]

le********@yahoo.com (Lee Rouse) wrote in
news:81*************************@posting.google.co m:

[]

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'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).
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
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).
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.
Until all workstations are at SR1a+ and Jet SP 4 SP6 or SP8, don't
waste your time with anything else.
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. . . .
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.
. . . 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.

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]

le********@yahoo.com (Lee Rouse) wrote:

This is going to be a rather lengthy "question".
We much prefer lengthy questions to very short questions.
During the past week,
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
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.

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]

Tony Toews <tt****@telusplanet.net> wrote in
news:l1********************************@4ax.com:

le********@yahoo.com (Lee Rouse) wrote:

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.

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

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]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

Tony Toews <tt****@telusplanet.net> wrote in
news:l1********************************@4ax.com:

le********@yahoo.com (Lee Rouse) wrote:

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.

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

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

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

[Lee]

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

Lee
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

Tony Toews <tt****@telusplanet.net> wrote in
news:l1********************************@4ax.com:

le********@yahoo.com (Lee Rouse) wrote:

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.

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

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

[Lee]

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

I can answer that one. Try http://support.microsoft.com/default.aspx?kbid=239114
Lee

[David W. Fenton]

"Lee" <lr*************@cox.net> wrote in
news:zveXb.4962$Yj.888@lakeread02:

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

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]

"Randy Harris" <ra***@SpamFree.com> asked in message
news:eh********************@newssvr28.news.prodigy .com...

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

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:
=fGetProductVersion(SysCmd(9) & "msaccess.exe")
and the one for the JET service pack:
=fGetProductVersion(fReturnSysDir() & "\msjet40.dll")

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]

"David W. Fenton" <dX********@bway.net.invalid> wrote:

All the computers in our agency have been upgraded to Jet SP8.
That was the first thing I did.
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.

Ah, another corroborating posting that mixing Jet versions doe lead to corruptions.
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.
Whereas I pop up a warning message. But same difference.
It's too easy for machines to end up reverted to
earlier versions after re-installs.

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]

Tony Toews wrote:

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.

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

This is something Lee can check out. In the exit command code I'd pur the following
Private Sub CommandExit_Click
On Error Goto Err_CommandExit_Click

If Me.Dirty Then Docmd.RunCommand acCmdSaveRecord
Docmd.Close acForm,"This FormName",acSaveNo

Err_CommandExit_Click
Exit Sub

Err_CommandExit_Click
If Err.number <> 2501 then msgbox err.description
resume Exit_CommandExit_Click

end sub

[Lee]

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" <oi*@vinegar.com> wrote in message
news:40***************@vinegar.com...

Tony Toews wrote:

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.
Hmm, now this is interesting. But I have no good answer.

This is something Lee can check out. In the exit command code I'd pur the

following Private Sub CommandExit_Click
On Error Goto Err_CommandExit_Click

If Me.Dirty Then Docmd.RunCommand acCmdSaveRecord
Docmd.Close acForm,"This FormName",acSaveNo

Err_CommandExit_Click
Exit Sub

Err_CommandExit_Click
If Err.number <> 2501 then msgbox err.description
resume Exit_CommandExit_Click

end sub

[Lee]

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" <lr*************@cox.net> wrote in message
news:E%nXb.6445$Yj.5843@lakeread02...

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" <oi*@vinegar.com> wrote in message
news:40***************@vinegar.com...

Tony Toews wrote:

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

Hmm, now this is interesting. But I have no good answer.
This is something Lee can check out. In the exit command code I'd pur

the following

Private Sub CommandExit_Click
On Error Goto Err_CommandExit_Click

If Me.Dirty Then Docmd.RunCommand acCmdSaveRecord
Docmd.Close acForm,"This FormName",acSaveNo

Err_CommandExit_Click
Exit Sub

Err_CommandExit_Click
If Err.number <> 2501 then msgbox err.description
resume Exit_CommandExit_Click

end sub

[David W. Fenton]

Tony Toews <tt****@telusplanet.net> wrote in
news:3g********************************@4ax.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote:

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

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.

Ah, another corroborating posting that mixing Jet versions doe
lead to corruptions.

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.

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.

Whereas I pop up a warning message. But same difference.

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.

It's too easy for machines to end up reverted to
earlier versions after re-installs.

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

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

[David W. Fenton]

"Lee" <lr*************@cox.net> wrote in
news:5yoXb.6719$Yj.5921@lakeread02:

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

Ah. Novell.

Novell servers are problematic in terms of corruption.

I would never consent to building an Access application whose data
would live on a Novell server without a contract worded in such a
way as to hold me blameless for any corruption.

Windows servers, though not without their own problems, tend to work
more reliably.

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

[Bas Cost Budde]

David W. Fenton wrote:

Ah. Novell.

Novell servers are problematic in terms of corruption.
I have experienced that. Of 6000 records, only three were corrupt, so
maybe I was lucky.
Windows servers, though not without their own problems, tend to work
more reliably.

Do you have any experience with *nix/samba? It is running in my office
now for (counts) 4 years without complaints (backend on server, you know
the stuff), but I'm only one of two users.

--
Bas Cost Budde
http://www.heuveltop.org/BasCB
but the domain is nl

[David W. Fenton]

Bas Cost Budde <ba*@heuveltop.org> wrote in
news:c0**********@news2.solcon.nl:

David W. Fenton wrote:

Ah. Novell.

Novell servers are problematic in terms of corruption.

I have experienced that. Of 6000 records, only three were corrupt,
so maybe I was lucky.

Well, Netware settings can be adjusted to work OK, if you have the
cooperation of the Novell sysadmin.

Windows servers, though not without their own problems, tend to
work more reliably.

Do you have any experience with *nix/samba? It is running in my
office now for (counts) 4 years without complaints (backend on
server, you know the stuff), but I'm only one of two users.

No, I have none.

I would avoid it just as strenuously as Novell.

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

[Salad]

"David W. Fenton" wrote:

Do you have any experience with *nix/samba? It is running in my
office now for (counts) 4 years without complaints (backend on
server, you know the stuff), but I'm only one of two users.

No, I have none.

I would avoid it just as strenuously as Novell.

Bullshit.

If Access can't run reliably on Novell then it can't run reliably on MS
OSs unless MS has adapted their OS and products so that MS Products
only run on MS operating systems. Apple pursued that stategy and lost.

[Salad]

Lee wrote:

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

What is Client 34? I would think client 16,32,64,128 would be valid clients
depending on the features of an OS. 34 is wildely off binary increments.

[Lee]

Actually, it's Client 3.4. Any networking in the branch of state government
I work for is required to use Novell. Version 3.4 is for 95/98 machines. See
http://download.novell.com/ctrl for more information.

Lee

"Salad" <oi*@vinegar.com> wrote in message
news:40***************@vinegar.com...

Lee wrote:

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
What is Client 34? I would think client 16,32,64,128 would be valid

clients depending on the features of an OS. 34 is wildely off binary increments.

[Lee]

It's worth rechecking. Also, I don't think that all machines have been upped
to SR1a. I'll check that too. Ah, Sunday at the office.....

Lee
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:3g********************************@4ax.com...

"David W. Fenton" <dX********@bway.net.invalid> wrote:

All the computers in our agency have been upgraded to Jet SP8.
That was the first thing I did.
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.

Ah, another corroborating posting that mixing Jet versions doe lead to

corruptions.

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.
Whereas I pop up a warning message. But same difference.

It's too easy for machines to end up reverted to
earlier versions after re-installs.

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]

Lee wrote:

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

One other thing to try. Unless I am mistaken, the problem exists for a certain
form. Create a new blank form. Open the old form and copy/paste the controls
to the new form. Open up the old code window, select all code and paste into
new form. Delete form. Compact database. Now rename the new form to the old
form name. Or you can create a blank mdb and import the form. In the
production database delete the form and compact. Then reimport the form from
the new mdb. Also, make sure you've done a CompileAll.

[Tony Toews]

Salad <oi*@vinegar.com> wrote:

> Do you have any experience with *nix/samba? It is running in my
> office now for (counts) 4 years without complaints (backend on
> server, you know the stuff), but I'm only one of two users.

No, I have none.

I would avoid it just as strenuously as Novell.

Bullshit.

If Access can't run reliably on Novell then it can't run reliably on MS
OSs unless MS has adapted their OS and products so that MS Products
only run on MS operating systems. Apple pursued that stategy and lost.

I don't recall the details, if they've ever been mentioned, but it's my understanding
that the phantom locks with Jet places on the .ldb files isn't perfectly implemented
in some versions of Samba. And furthermore this behaviour isn't entirely documented
by MS.

But hey, I sure could be wrong.

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 Toews]

"David W. Fenton" <dX********@bway.net.invalid> wrote:

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

Ah. Novell.

Novell servers are problematic in terms of corruption.

Some versions, particularly of their client software, are definitely flaky.
Others??? <shrug> I think so because I've seen Novell KB articles specifically
referencing some versions of client software.

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 Toews]

"Lee" <lr*************@cox.net> wrote:

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

But the corruptions could be caused by one system but the first computer informing
you that a given MDB is corrupted could be a totally different system.

That said it's possible that different versions of client software could be a cause.
This is certainly true for Jet versions.

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]

Tony Toews <tt****@telusplanet.net> wrote in
news:d5********************************@4ax.com:

"Lee" <lr*************@cox.net> wrote:

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

But the corruptions could be caused by one system but the first
computer informing you that a given MDB is corrupted could be a
totally different system.

That said it's possible that different versions of client software
could be a cause. This is certainly true for Jet versions.

Another thing we used to worry about was anti-virus software, back
in the days when everyone but Symantec bought their MDB scanning
code from Peter Miller. In those days, Norton was very problematic,
so I always turned off scanning of MDBs.

Is that danger past with current versions of all AV software?

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

[Tony Toews]

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Another thing we used to worry about was anti-virus software, back
in the days when everyone but Symantec bought their MDB scanning
code from Peter Miller. In those days, Norton was very problematic,
so I always turned off scanning of MDBs.

Is that danger past with current versions of all AV software?

There have been some drastic performance slowdowns with some of the weekly updates
from assorted vendors. But the next week update fixed those. Mostly because MDB/MDE
scanning was accidentally turned on for that week.

I suspect most vendors no longer scan MDB/MDEs by default.

So no I haven't seen any lately.

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

[Lee]

Several of you mentioned that it is important to have the latest version of
MSJET40.dll, as well as Office SR1a on each workstation. As I mentioned in
an earlier posting, all workstations have version 8 of MSJET. Also, I am in
the process of getting Office updates for all computers. Once this has been
done, my Office Applications indicate that I have Service Pack 3, but say
nothing about SR1. Forgive my ignorance, but can I assume that if I have SP3
on each machine, I have SR1a as well?

Thanks,

Lee
"Lee Rouse" <le********@yahoo.com> wrote in message
news:81*************************@posting.google.co m...

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