I have recently placed an access database (back end) on a network folder.
The standalone pc's accessing the network have in their own respective C
drives a copy of the database (minus the table). I have linked the backend
source table to these front end database copies.
The networking has been working nicely but the other day, I got a message
when trying to access the database stating that the format is not a
recognizable one... ie i simply could not open it.
I think it was corrupted. Anyhow, I deleted the database and I went to use a
copy of a front end database, minus the data to recreate the main network
database. But these too were corrupted as I could not open them either.
Finally I managed to get a seperate backup copy of the database and set it
up as the network database to replace the corrupted one.

Note the following if these may have contributed to the corruption:
- I did not split the database as i had simply copied the database to each
of the pc's on the network (minus the table data) and then linked the source
backend table to the access database copies in the pc's.
- I had not set up a workgroup - do I really need to ? will that affect the
database in the long term ?
- in the Options section, under the Default Record Locking area, i had
ticked "no locks". I feel maybe I should have ticked "Edited Record" to have
avoided the corruption of the database as there would not have been a clash
in editing a particular record between users at any given time.
- finally, i did not compact and repair the database and certainly not on a
regular basis as recommended by microsoft, which may have contributed to the
corruption ?
Any comments from the above as to the possible cause so I can avoid it in
the future.

Hi,
I'm about to implement the same thing. Is there a place somewhere which
would tell us how to properly set up something like this?

Thanks

I think your problems stemmed from not using a split database. I've
read that the more traffic there is during read/write occuring at the
same time, the better chance of corruption. As I understand it, the
database being split would prevent or lessen the chance of it
happening.

I would also use the compac/repair at a regular basis.

Good luck!

Dave

"Gary" <g45340@hotmail.com> wrote in
news:42a84bbd$0$10315$afc38c87@news.optusnet.com.a u:
[color=blue]
> I have recently placed an access database (back end) on a network
> folder. The standalone pc's accessing the network have in their
> own respective C drives a copy of the database (minus the table).
> I have linked the backend source table to these front end database
> copies. The networking has been working nicely but the other day,
> I got a message when trying to access the database stating that
> the format is not a recognizable one... ie i simply could not open
> it. . . .[/color]

That means that the back end has been flagged as possibly corrupt.
It doesn't necessarily mean it *is* corrupt.

Work your way through:

http://www.granite.ab.ca/access/corruptmdbs.htm

That has everything you need for diagnosing the problem.
[color=blue]
> . . . I think it was corrupted. Anyhow, I deleted the database and
> I went to use a copy of a front end database, minus the data to
> recreate the main network database. But these too were corrupted
> as I could not open them either. Finally I managed to get a
> seperate backup copy of the database and set it up as the network
> database to replace the corrupted one.[/color]

Why didn't you just make a copy of the back end and try to compact
it?
[color=blue]
> Note the following if these may have contributed to the
> corruption:[/color]
[color=blue]
> - I did not split the database as i had simply copied
> the database to each of the pc's on the network (minus the table
> data) and then linked the source backend table to the access
> database copies in the pc's.[/color]

I can't see how that would cause a problem. It doesn't matter if you
have unused data tables in the front ends.
[color=blue]
> - I had not set up a workgroup - do I
> really need to ? will that affect the database in the long term ?[/color]

Well, you're always using a workgroup file, whether you set it or
not, and logging in silently as ADMIN. But, no this has nothing to
do with the problem.
[color=blue]
> - in the Options section, under the Default Record Locking area, i
> had ticked "no locks". I feel maybe I should have ticked "Edited
> Record" to have avoided the corruption of the database as there
> would not have been a clash in editing a particular record between
> users at any given time.[/color]

No, optimistic or pessimistic locking has no effect whatsoever on
database corruption. That choice only affects how edit collisions
are determined, and works only when everything is already operating
correctly.
[color=blue]
> - finally, i did not compact and repair
> the database and certainly not on a regular basis as recommended
> by microsoft, which may have contributed to the corruption ?[/color]

Yes, regular maintenance is absolutely necessary to insure the
long-term health of your data. It could be that your database was
carrying undetected corruption for a very long time. I've seen
databases entirely lost from corruption that was then found to have
been present in backups going back weeks and months.

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

"DaveA" <nydiroth@yahoo.com> wrote in
news:1118335981.110094.165430@f14g2000cwb.googlegr oups.com:
[color=blue]
> I think your problems stemmed from not using a split database. . .[/color]

Er, I read this in the original post:

The standalone pc's accessing the network have in their own
respective C drives a copy of the database (minus the table). I
have linked the backend source table to these front end
database copies.

as indicating that it was already split.

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

"ken" <gevayl@gmail.com> wrote in news:1118330047.085982.107660
@o13g2000cwo.googlegroups.com:
[color=blue]
> Hi,
> I'm about to implement the same thing. Is there a place somewhere which
> would tell us how to properly set up something like this?
>
> Thanks
>
>[/color]

Yes. It's called, "install a real RDBMS system on the server" and store
your data in that. Be it MySQL, PostGres 8.0, Oracle, DB2, SQL Server,
Firebird/Interbase, whathaveyou.

Not only will it be faster, it'll be more robust.

by using a remote MDB file with a client MDB front-end, you still run the
risk of a network outage, frustrated user, wandering cat, whathaveyou,
doing something to interrupt your connecton to the non-comingled MDB file
while their "client" is trying to write data to the backend MDB file, and
it'll get corrupted. Like what happened to you.

Except for MySQL (until MySQL 5.0 is released), all the other RDBMS have
what is known as a transaction, and all updates happen witin the confines
of a transaction, which can roll back all changes made for a session if a
hiccup like the above occurs, keeping the rest of the data intact.

corey lawson <corey.lawson@worldnetdotattdotnet> wrote in
news:Xns967227D9C8D9coreylawsonworldnetd@127.0.0.1 :
[color=blue]
> "ken" <gevayl@gmail.com> wrote in news:1118330047.085982.107660
> @o13g2000cwo.googlegroups.com:
>[color=green]
>> I'm about to implement the same thing. Is there a place somewhere
>> which would tell us how to properly set up something like this?[/color]
>
> Yes. It's called, "install a real RDBMS system on the server" and
> store your data in that. Be it MySQL, PostGres 8.0, Oracle, DB2,
> SQL Server, Firebird/Interbase, whathaveyou.[/color]

This is an overly pessimistic answer.

I have never once had a client who used a server back end, and not
one client has ever lost data, except to bugs in Jet (the early
versions of Jet 4 were disastrous -- a client lost 3 whole
records!!!) or to lack of backups.
[color=blue]
> Not only will it be faster, it'll be more robust.[/color]

No, it won't necessarily be faster. It may, in fact, be slower after
a conversion to a server back end, unless your original front end
was engineered with that conversion in mind.
[color=blue]
> by using a remote MDB file with a client MDB front-end, you still
> run the risk of a network outage, frustrated user, wandering cat,
> whathaveyou, doing something to interrupt your connecton to the
> non-comingled MDB file while their "client" is trying to write
> data to the backend MDB file, and it'll get corrupted. Like what
> happened to you.[/color]

Yes, that risk is always there, but in my more than 10 years of
experience with Access applications using Jet back ends, data loss
is very, very uncommon.
[color=blue]
> Except for MySQL (until MySQL 5.0 is released), all the other
> RDBMS have what is known as a transaction, and all updates happen
> witin the confines of a transaction, which can roll back all
> changes made for a session if a hiccup like the above occurs,
> keeping the rest of the data intact.[/color]

If your data is very important and the possibility of the loss of
any data at all untenable, then, yes, a server back end could be a
good idea.

But it comes with substantial administrative overhead, and requires
a lot more knowledge to get running efficiently than a pure
Access/Jet solution.

People who have recurrent corruption with Access databases simply
aren't competent at designing applications and adminstering their
network/application.

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