How many end users can you name that can actually distinguish between normal
database behavior and unpredictable behavior. It has been my experience
that few can figure this out. Also in a multi-user environment giving people
the ability to repair a database just strikes me as stupid. If one person
is able to repair the database (open exclusively), everyone else will be
locked out (unpredictable behavior) and start a cascading repairing situation.
Lastly, there is a big difference between the help file and your article.
Microsoft states in the article you reference that one should never repair
a database unless specifically asked to. In the help file, it states that
it will not always recognize when it is corrupted and therefore should be
repaired when anybody feels it is behaving unpredictably. I see a large
difference here.

As far as a Novell server the database I repair on a regular basis reside
on a novell server (5.1). I do the repair/compact after a nightly backup,
since I was aware that it does ocassionally corrupt the database. This does
happen very infrequently (it has been 9 months since the last time this happened),
if you take precuationary steps this will greatly reduce database corruption.
It is not luck.

Finally, my "luck" will not need to continue much longer as we are in the
final stages of replacing the database (interbase/linux).

Marc



"Douglas J. Steele" <djsteele@canada.com> wrote:
>Providing a RepairDatabase method for use "if their database behaves
>unpredictably" is a big difference from running Repair on a regular basis.
>
>You've been lucky so far. I hope your luck continues.
>
>--
>Doug Steele, Microsoft Access MVP
>http://I.Am/DougSteele/
>
>
>"marc" <whale@ultranet.com> wrote in message
>news:3b3728ec$1@news.devx.com...
>>
>> A quote from Access 97 help:
>>
>> "When you attempt to open or compact a corrupted database, a run-time

>error
>> usually occurs. In some situations, however, a corrupted database may

not
>> be detected, and no error occurs. It's a good idea to provide your users
>> with a way to use the RepairDatabase method in your application if their
>> database behaves unpredictably."
>>
>> Microsft even goes so far in this help file to allow end users to perfrom
>> db admin functions. It seems they have changed their mind about the use
>> of the repair function. Undoubtly microsoft found a bug which made them
>> changed their recomendation. I will still continue my practice becuase

I
>> have found it prevents the database from becoming corrupted, and therefore
>> data loss.
>>
>> I will also wish you good luck with your projects, I know you will need

>it.
>>
>> Marc
>>
>>
>>
>> "Douglas J. Steele" <djsteele@canada.com> wrote:
>> >Feel free to continue your practice.
>> >
>> >Good luck. You'll probably need it.
>> >
>> >--
>> >Doug Steele, Microsoft Access MVP
>> >http://I.Am/DougSteele/
>> >
>> >
>> >"marc" <whale@ultranet.com> wrote in message
>> >news:3b336171$1@news.devx.com...
>> >>
>> >> I have lost more data not repairing a database than repairing a

>database
>> >(none).
>> >> Multiple times the database was corrupted beyond repair and the data

>> had
>> >> to be restored from backup. If you find having people re-enter a days
>> >worth
>> >> of work acceptable, than I would not repair a database. I do not find
>> >this
>> >> acceptable. Additionally the repair is done a night, after a full

>backup
>> >> is completed, if the database is lost a complete backup is available.
>> >Your
>> >> faith in Access's repair capabilities leads me to believe you have

not
>> >dealt
>> >> with large Access databases.
>> >>
>> >> Marc
>> >>
>> >> "Douglas J. Steele" <djsteele@canada.com> wrote:
>> >> >NEVER repair an Access database unless Access explicitly tells you

to.
>> >You
>> >> >actually run the risk of corrupting the database if you repair it
>> >> >unnecessarily.
>> >> >
>> >> >See http://support.microsoft.com/support.../q279/3/34.asp

for
>> >more
>> >> >details.
>> >> >
>> >> >HTH
>> >> >
>> >> >--
>> >> >Doug Steele, Microsoft Access MVP
>> >> >http://I.Am/DougSteele/
>> >> >
>> >> >
>> >> >"marc" <whale@ultranet.com> wrote in message
>> >news:3b30955d@news.devx.com...
>> >> >>
>> >> >> I have found preventative maintenence to be a good solution to this
>> >> >problem.
>> >> >> Write an application that repairs and compacts the database at

>night.
>> >> >This
>> >> >> will greatly reduce the number of database corruptions that occur

(1
>> >this
>> >> >> past year with the one access database we have, down from about

2 a
>> >week).
>> >> >>
>> >> >> Marc
>> >> >>
>> >> >> "Raffaele" <software@infolandsys.com> wrote:
>> >> >> >
>> >> >> >I'm working with a VB/ADO multiuser application using many Access

>> 97
>> >> >databases,
>> >> >> >all of them placed on a file-server NT station.
>> >> >> >I noticed that some DBs get corrupted quite often, causing open

>errors
>> >> to
>> >> >> >my programs and so needing a repair & compact via Access or JRO's
>> >> >CompactDatabase
>> >> >> >method.
>> >> >> >
>> >> >> >I'd like to know if someone ever found a way to know in advance

if
>> a
>> >> >database
>> >> >> >"is going to get" corrupted, before the Open method of a Connection
>> >> >object
>> >> >> >fails, so I can develop a background task that analyzes in turn

the
>> >> >databases
>> >> >> >and, if necessary, it repairs them.
>> >> >> >
>> >> >> >Many thanks
>> >> >> >
>> >> >> >R. Bafunno
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >

>>

>
>