|
|
"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns9657908503D5
Cdfentonbwaynetinval
i@24.168.128.86...
> "(PeteCresswell)" <x@y.z.invalid> wrote in
> news:ffad819i4oqkr2j
orvti0nvk97can9q31m@
4ax.com:
>
>
> But that happens very, very seldom. I've only seen actual corruption
> to the point of data loss a couple of times in 10 years of Access
> development (all Jet back ends). And that happened in only two
> different kinds of cases:
>
> 1. the client was doing no maintenance on the db at all, and storing
> it on a workstation running unstable software that was constantly
> crashing. The most memorable of these was back in the days of
> Win3.x, and the client was running WordPerfect 6.0 on the
> workstation where the Access 2 data file was stored.
>
> 2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
> who did lose 3 records to corruption, ones that couldn't be
> recovered after a corrupted primary key index.
>
> I also once corrupted a client's database by running a huge append
> operation against the live data file, and then killing the Access
> process. I intended to run it against test data, but made a mistake.
> My second mistake was killing the process. The file had to be sent
> to Peter Miller for recovery and all the data was recovered.
>
> I currently have a client with an unreliable network who is getting
> "disk or network error" messages frequently, and they have not as
> yet experienced any corruption of their replicated Jet 3.5 back end.
>
> So, I'd say that Jet is not all the prone to corruption at all.
>
> Of course, I'm defining corruption to be restricted to
> non-recoverable corruption, since the only reason server databases
> don't lose data is because you can run the transaction logs to
> rebuild a corrupted data store. That's not the same as never
> corrupting the data store (which does, in fact, happen), so, since
> you're giving the benefit of the doubt to the server back end, I'm
> giving the same to Jet.
>
Ok, I usually lurk, but I have some questions about corruption. I've read
that the databases should be split, with data on the network, and the forms
and queries on each individual pc. We use Acess 97, not split, but with no
queries or forms. All of the user input and queries are done through
programs written in Visual C++ 6.0. The database lives on the network, the
programs live on each users' PC. I didn't write the actual database code,
so I assume it uses JET. It doesn't use ODBC. Most of the users have XP,
but a few still have Win98, so when I do get a chance to make changes in the
code, I compile it for both, and have separate installs. I do a compact and
repair on the databases about once a month, when everyone else has gone
home. The databases are small: the largest is about 30-35MB.
We get corruption, oh, maybe once a year or so. The network is slow
perhaps, then they start getting error messages. I kick everyone out, and
see records with #ERROR all across. I've recovered the data by copying
everything to Excel in the bad database, and then copying it back. (I've
got to do some funky stuff, since there are autonumber fields to deal with
as well.) We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried a repair
from 2002, and it did work (converting the database as well), so I managed
to give them some of the data they had entered. Some was still lost.
So, other than not having enough time to work on this project, and not
knowing exactly how the database access* works, what am I doing wrong? I
don't like any corruption, but it still occasionally happens. Do I need a
split database when the database only has tables? Tell me more about
transaction logs to rebuild corrupted data stores. (I don't usually have
physical access to the computer the data resides on, just a network map to
the drive.)
-k
*access, not Access. Although I certainly don't know exactly how the
database Access works either!
|
|