| John Vinson 2005-05-16, 8:24 pm |
| On Mon, 16 May 2005 18:16:24 GMT, "karen"
< nospambugarsnotspam@
ix.netcomspamnot.com> wrote:
>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.
Essentailly, you already HAVE a split database: the tables in a .mdb
file on the backend, and the user interface application distributed
onto each frontend. It's only different in that your frontend is
implemented in VC++ rather than in Access. You'll get no benefit from
splitting since basically there is nothing to split!
>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.
Hm. I don't see clearly how going to Excel buys you anything! In that
situation I'd be inclined to a) keep good current backups and simply
trash the corrupt database and simply recover from the backup; b) have
a routine of Compacting the database (you may well be doing so); and
c) if necessary, create a brand-new empty database and use File... Get
External Data... Import to import all the tables. For a damaged table
it may be necessary to create the table empty, Link to the damaged
table, and run one or more Append queries to migrate the data.
>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.)
Transaction logs are available natively in SQL/Server, but not in
Access JET databases. They can be implemented in JET but it would be a
REALLY big painful job - simpler to install MSDE and move the data to
SQL!
It may well be worth your while to check out Tony's excellent FAQ at
http://www.granite.ab.ca/access/corruptmdbs.htm
for suggestions to prevent (or at least inhibit) corruption.
John W. Vinson[MVP]
|