Is there less chance of data corruption with MDE file.

External Since: Dec 13, 2004 Posts: 7

Hi All,
I've read this thread because I'm experiencing a similiar problem. I have a
multi-user DB which is experiencing a lot of corruption; I'm in the process
of splitting it and putting a MDB on each users desktop. My problem is that
of the 10 users, 4 are at a lower version of access, so I can't distribute an
MDE to all users. I tried running one of our reports from the new FE (mdb) ,
and I got a lot of paging errors. It seemed to work better with an MDE, which
is what I'd like to use. My question is, would it be worth it to upgrade the
other 4 users so I can have everyone utilize an MDE? can I use a combo of
MDE/MDB or would that be a nightmare for me?
If MDB works just as well, should I go just stick with that?
Thanks for any infomation you can send my way....
"ThomasAJ" wrote:

> I have a database that is split in two for code and data.
>
> Currently in my small LAN I point users' desktop icons to CODE.MDB that is
> on the main PC. Is it better from "data corruption (ie DATA.MDB)" perspective
> to create a CODE.MDE and distribute that to the users' PCs.
>
> NOTE Please don't go into linked tables issues, licences etc.
> I just want opinions on whether there is less chance of data corruption
> should a user PC for example fail while the application is open. Or it makes
> no difference.
>
> --
> Regards
> Tom

External Since: May 11, 2004 Posts: 187

Hi,

Tom;
It is better to distribute MDE rather than MDB. That way no one
accidentally or maliciously fiddles with your code. It will likely mean
more work for you to do when the network changes or the placement of the
back end is moved, etc.

Abbey;
Yours is a tougher issue and while the above suggestion holds true for you
as well, I suggest that you save a copy of your Front End in the earliest
version you have to support and make the MDE in that version after you've
fully debugged it and distribute that MDE to your users. Of course any cost
consideration has to take into account the value of your time and the depth
of your workload. It may be less expensive to simply force everyone to the
latest version that's already in place and debugged.

The usual causes of data corruption in the Access back ends: Users powering
off their PCs without going through an orderly shut-down. Flaky network
interface card(s) in the PC(s). Network problems. There is a bias toward
greater reliability with the MDE since no one can get into the code and
cause it to do something strange.

HTH
--
-Larry-
--

"Abbey Normal" <AbbeyNormal DeleteThis @discussions.microsoft.com> wrote in message
news:9C4E2858-4658-4D6C-A44B-085735DB9301@microsoft.com...
> Hi All,
> I've read this thread because I'm experiencing a similiar problem. I have
a
> multi-user DB which is experiencing a lot of corruption; I'm in the
process
> of splitting it and putting a MDB on each users desktop. My problem is
that
> of the 10 users, 4 are at a lower version of access, so I can't distribute
an
> MDE to all users. I tried running one of our reports from the new FE (mdb)
,
> and I got a lot of paging errors. It seemed to work better with an MDE,
which
> is what I'd like to use. My question is, would it be worth it to upgrade
the
> other 4 users so I can have everyone utilize an MDE? can I use a combo of
> MDE/MDB or would that be a nightmare for me?
> If MDB works just as well, should I go just stick with that?
> Thanks for any infomation you can send my way....
> "ThomasAJ" wrote:
>
  > > I have a database that is split in two for code and data.
  > >
  > > Currently in my small LAN I point users' desktop icons to CODE.MDB that
is
  > > on the main PC. Is it better from "data corruption (ie DATA.MDB)"
perspective
  > > to create a CODE.MDE and distribute that to the users' PCs.
  > >
  > > NOTE Please don't go into linked tables issues, licences etc.
  > > I just want opinions on whether there is less chance of data corruption
  > > should a user PC for example fail while the application is open. Or it
makes
  > > no difference.
  > >
  > > --
  > > Regards
  > > Tom