database keeps corrupting

[macroapa]

Hi,

I have a backend db with 1 table which has a PK. The backend table is
populated by some word VBA code and the records then edited over a
period of time using an access front end.

Now every so often, the table is getting corrupted and a record will
show all #ERROR.

This means that the front end queries all fail to work and no-one can
actuall work!!!!

The only way to correct it I have found is to copy the back end,
perform a compact and repair, then open the table where I can now
delete the rouge record (as it no longer shows #ERROR, but rubbish
data) and then copy the back end back over the existing back end.

I cant perform a compact and repair direct on the back end as people
are connected to it and constantly writing to it.

Is there a better way to deal with this situation?

Thanks.

 

[John W. Vinson]

are connected to it and constantly writing to it.

Is there a better way to deal with this situation?

Obviously, find the cause of the corruption and fix it!

This is a split database so you're (I hope) not letting multiple users
directly open the database directly, right?

Are any of the users connecting over a Wide Area Network, or wireless
connections? Is your LAN fast and stable?

Check out the suggestion at Tony Toews' corruption FAQ:
http://www.granite.ab.ca/access/corruptmdbs.htm

You might also want to consider upsizing to SQL/Server - it's now much more
affordable than it once was; see Tony's upsizing hints on the same webpage.

 

[(PeteCresswell)]

Per macroapa:

I have a backend db with 1 table which has a PK. The backend table is
populated by some word VBA code and the records then edited over a
period of time using an access front end.

Now every so often, the table is getting corrupted and a record will
show all #ERROR.

The Tony Towes link probably has all bases covered, but I would
share the two causes of corruption that I have encountered:

1) Flaky NIC on one of the user's PC.

2) Something goofy in the file server that the back end DB
was on.


Never found out why the file server was causing corruptions, but
changing servers made the problem go away and going back to the
problem server made it come back.

Both problems were intermittent.

 

[Tony Toews]

You might also want to consider upsizing to SQL/Server - it's now much more
affordable than it once was; see Tony's upsizing hints on the same webpage.

Actually there's always been a free version with
size/throttling/memory limitiations since SQL Server 2000. That
said those size/throttling limitations weren't that significant with
the usual size of MS Access applications. The throttling, has been
removed in at least SQL Server 2008 and maybe even SQL Server 2005 but
I can't recall now.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Tony Toews]

I would
share the two causes of corruption that I have encountered:

1) Flaky NIC on one of the user's PC.

2) Something goofy in the file server that the back end DB
was on.

Agreed. That's certainly what I"ve seen as well as read in the
newsgroups.

Both problems were intermittent.

And that's the worst part. Well, not quite. They were quite
consistent in the days of the OpLocks problem but that's long been
fixed.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[David W. Fenton]

Actually there's always been a free version with
size/throttling/memory limitiations since SQL Server 2000. That
said those size/throttling limitations weren't that significant
with the usual size of MS Access applications. The throttling,
has been removed in at least SQL Server 2008 and maybe even SQL
Server 2005 but I can't recall now.

I think, though, that one of the main problems of SQL Server Express
in a non-domain context is that you have to use SQL Server
authentication, which I find much less flexible than simply using
Windows authentication.

 

[Tony Toews]

I think, though, that one of the main problems of SQL Server Express
in a non-domain context is that you have to use SQL Server
authentication, which I find much less flexible than simply using
Windows authentication.

Good point.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[a a r o n . k e m p f]

Jet is a piece of shit database. Jet corrupts, it's impossible to
prevent.

Move to SQL Server.

Access Data Projects allow you to keep most of your existing forms /
reports

 

[a a r o n . k e m p f]

Actually there's always been a free version with
size/throttling/memory limitiations since SQL Server 7.0

 

[a a r o n . k e m p f]

David;

What the **** are you talking about, kid?

you're saying that u can't use Windows Auth without a domain??

ROFLMAO

where do you come up with these lies?

I use Windows Auth _ALL_ the time without a domain you fucking retard
loser liar

 

[a a r o n . k e m p f]

Tony;

eat shit and learn the truth, kid

Good point.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated seehttp://www.autofeupdater.com/- Hide quoted text -

- Show quoted text -

 

[a a r o n . k e m p f]

95% of the fortune 500 use Active Directory, btw

 

[a a r o n . k e m p f]

Tony;

here's the link that talks about MSDE 1.0 that shipped with SQL Server
7.0 and /or VS 6.0

http://support.microsoft.com/kb/232570/