ReadOnly BE or FE

[Guest]

Probably doesn't matter but thought I'd better check.

If only one person edits the db... and others just need to readonly and
print reports etc. Should you distribute the FE mde as read only... or make
the BE mdb read only? The BE will be updated and emailed probably when there
are enough edits to warrant it.

Thanks!

 

[Douglas J. Steele]

The FE being read-only has no impact on the BE.

However, are you sure you're using the terms correctly? It's seldom the BE
that's "updated and emailed". The FE contains the queries, forms, reports,
macros and modules. The BE contains the tables and relationships.

 

[Guest]

Thanks ... yes I am using the terms correctly. In our application the BE will
be updated by one person as data changes it is on one persons laptop and we
don't have a server. The only way the others will get the changes is if the
person editing gives it to them. So, it will be emailed...but I don't want
others that view the data to be able to change it. In the past we ended up
with multiple BE's and then when reports were run they were wrong. We can't
email a replicated BE because of corruption possibilities and there is no way
to sync it because we don't have a server. We are checking into using a
fileshare but we still don't want numerous people editing the data because
only one person will be getting the applications and will see the data that
should be changed in the DB.

So, you are saying that making the forms in the FE to not allow input is not
the way to go? Just make the BE readonly on distribution?


Thanks!

 

[Douglas J. Steele]

Sorry, I understood "distribute the FE mde as read only" to mean setting the
MDE file as read-only.

Making the forms not allow input is probably a good idea, but remember that
anyone who wants to will be able to create a new database, link to the BE
and update it to their heart's content.

You could apply Access User-Level Security, but even that isn't fool-proof.

 

[David W. Fenton]

We can't
email a replicated BE. . .

You can't email a replicated BE in any scenario, because it doesn't
work -- it breaks replication.

because of corruption possibilities and there is no way
to sync it because we don't have a server.

Er, you don't need a dedicated server to use indirect replication.
All you need is any PC acting as a server. I have plenty of clients
using replication who have no server.

We are checking into using a
fileshare but we still don't want numerous people editing the data
because only one person will be getting the applications and will
see the data that should be changed in the DB.

A fileshare won't change anything if the users aren't on the same
LAN.

If they *are* on the same LAN, then you should be considering Jet
user-level security as a way to restrict the users' permission
levels. And you won't have any need for replication.

 

[Guest]

Thanks for both of your responses. Actually we have used a replicated BE
zipped it emailed it and it synced fine... but I have learned that over time
it will make dead replica sets. (Maybe I just don't understand the syncing
process behind the scenes) But, in any case I will take your suggestions and
figure out the best course of action.

But, as always I appreciate your responses!

 

[David W. Fenton]

Actually we have used a replicated BE
zipped it emailed it and it synced fine... but I have learned that
over time it will make dead replica sets. (Maybe I just don't
understand the syncing process behind the scenes)

Once replicas have data added into them that needs to be
synchronized with other replicas, they have to be left *in place*,
where the data was added/edite, and synched *in place*. That is one
of the ironclad and unavoidable rules of using Jet Replication. When
you violate it, Jet Replication can completely break down and you
can lose your data.

That's good enough reason for me to never break the rule.