Runtime and Split Database

[PBISMaryland]

Hi. I am getting myself a bit confused and thought a post may clear it a bit.

I have an Access database that I would like to distribute but do not what
users to be able to modify objects. Using a runtime version seems to have
solved that issue but I am interested in possibly splitting the database so
more than one user can access the backend. However, when I create the
runtime version how can I then connect to the back end through that
application. Sorry if this post sounds confusing but I am confused myself.

Bottom line: what steps should/could I take to allow more than one user to
use the application while protecting the objects from being changed or
deleted.

Thanks in advance.

 

[bhicks11 via AccessMonster.com]

Do you mean an MDE? Microsoft has a runtime version of Access that can be
included with an app when users don't have a full verions but I think you
mean a compiled MDE.

If so, heres a linke:

http://www.tek-tips.com/faqs.cfm?fid=91

You split the MDB and then compile the front end to an MDE. Make sure you
keep your MDB backed up. Your tables are linked automatically but if you
ever have problems you can go back to your MDB and relink. Keep everything
backed up. I think you will find it works well.


Bonnie
http://www.dataplus-svc.com

 

[PBISMaryland]

Thanks for the reply Bonnie. I am not 100% sure what I mean. Most users
will not have Access on the computers. I am guessing that an MDE would then
not work. Correct?

Thanks.

 

[bhicks11 via AccessMonster.com]

An mde will run with Access runtime. What did you mean when you said runtime?


Bonnie
http://www.dataplus-svc.com

Thanks for the reply Bonnie. I am not 100% sure what I mean. Most users
will not have Access on the computers. I am guessing that an MDE would then
not work. Correct?

Thanks.

Do you mean an MDE? Microsoft has a runtime version of Access that can be
included with an app when users don't have a full verions but I think you

[quoted text clipped - 26 lines]

 

[Rick Brandt]

Thanks for the reply Bonnie. I am not 100% sure what I mean. Most
users will not have Access on the computers. I am guessing that an
MDE would then not work. Correct?

The use of an MDE and the use of the runtime have nothing to do with each
other.

An MDE prevents viewing or altering code or code-based objects (forms,
reports, modules). It does this because the human readable code has been
compiled to a non-readable format and the readable part is stripped out of
the file.

The runtime is a "run-only" version of Access that lets users who don't have
a retail copy of Access use Access applications. Using that does nothing to
protect your design (unless you also use an MDE) because even if you
distribute your file with the runtime, that does nothing to prevent a user
with a full copy of Access from opening it. Your design would be safe from
users who had ONLY the runtime installed.

 

[PBISMaryland]

The users will most likely not have Access on their computers. I thought
then that the only way they can run the application I created was if they
then had the runtime version of Access. In an ideal world here is what I am
trying to accomplish:

I would like to have data stored on a server and have from 1 - 5 users (who
do not have a full version of Access) have the front-end on their computers.
I also do not want them to have access to modify or create reports or forms.

An mde will run with Access runtime. What did you mean when you said runtime?


Bonnie
http://www.dataplus-svc.com

Thanks for the reply Bonnie. I am not 100% sure what I mean. Most users
will not have Access on the computers. I am guessing that an MDE would then
not work. Correct?

Thanks.

Do you mean an MDE? Microsoft has a runtime version of Access that can be
included with an app when users don't have a full verions but I think you

[quoted text clipped - 26 lines]

Thanks in advance.

 

[bhicks11 via AccessMonster.com]

So compile the MDE for their desktops and install it with the runtime for
those that don't have Access on the PC's. There are a few considerations
that you should consider in regard to the MDE. Search help and review it
before compiling.

Bonnie
http://www.dataplus-svc.com

The users will most likely not have Access on their computers. I thought
then that the only way they can run the application I created was if they
then had the runtime version of Access. In an ideal world here is what I am
trying to accomplish:

I would like to have data stored on a server and have from 1 - 5 users (who
do not have a full version of Access) have the front-end on their computers.
I also do not want them to have access to modify or create reports or forms.

An mde will run with Access runtime. What did you mean when you said runtime?

[quoted text clipped - 12 lines]

 

[Klatuu]

I think you have received some cofusing thought mostly correct information.
I am posting in hopes I can clarify it some.

First about splitting a database.
You should always deploy your applications as split databaes. There are
multiple reasons to do do. The correct implemention is for each user to have
their own copy of the front end linked to the backend in a shared folder
where they have read, write, and delete privledges. These are important
because of the ldb file that is created, updated, and deleted when using an
access application.

I also recommend you use UNC paths rather than Drive Map paths when linking
to the back end. It is more efficient and it prevents any problems when all
users don't have the save drive letter mapped to the backed mdb location.

For those users who do not have a full install of Acces, you can install the
Access runtime which only allows execution of an Access application. No
changes to any Access objects is allowed. It has to be installed on each
user's computer.

It is not necessary to install Access or any other supporting software on
the server. Access is a file server database engine, not a client server
application like SQL Server. That means, that there is no requirement for
any software running on the server for an Access applicaiton. All the logic
and processing occur on the user's computer. That is the main reason it is a
bad idea to share one copy of an unsplit database or even one copy of a front
end database on the server. It is a much heavier impact on network traffic
and almost assures you will sooner or later have corruption in your database.

The decision as to whether to deploy the mdb or an mde to the users is up to
you. I recommend deploying only an mde, particularly if you have any users
with full Access installed.
--
Dave Hargis, Microsoft Access MVP

The users will most likely not have Access on their computers. I thought
then that the only way they can run the application I created was if they
then had the runtime version of Access. In an ideal world here is what I am
trying to accomplish:

I would like to have data stored on a server and have from 1 - 5 users (who
do not have a full version of Access) have the front-end on their computers.
I also do not want them to have access to modify or create reports or forms.

An mde will run with Access runtime. What did you mean when you said runtime?


Bonnie
http://www.dataplus-svc.com

Thanks for the reply Bonnie. I am not 100% sure what I mean. Most users
will not have Access on the computers. I am guessing that an MDE would then
not work. Correct?

Thanks.

Do you mean an MDE? Microsoft has a runtime version of Access that can be
included with an app when users don't have a full verions but I think you
[quoted text clipped - 26 lines]

Thanks in advance.

 

[bhicks11 via AccessMonster.com]

Thank you and Klatuu for the addition details/information. Just to be sure
of myself - was there something I said that was incorrect?

Bonnie
http://www.dataplus-svc.com

 

[Klatuu]

Bonnie,
I saw nothing really incorrect, but more incomplete. I was just trying to
add detailed information to help the OP.

 

[bhicks11 via AccessMonster.com]

Okay - thank!

Bonnie,
I saw nothing really incorrect, but more incomplete. I was just trying to
add detailed information to help the OP.

Thank you and Klatuu for the addition details/information. Just to be sure
of myself - was there something I said that was incorrect?

[quoted text clipped - 20 lines]

 

[Tony Toews [MVP]]

I also recommend you use UNC paths rather than Drive Map paths when linking
to the back end. It is more efficient

I don't see how using UNC is more efficient than drive letters.

and it prevents any problems when all
users don't have the save drive letter mapped to the backed mdb location.

Using drive letters was quite handy for me the developer at one
client. I did a Command Prompt Subst to point to a local folder
name and ran my app when testing on my system. Then if I needed to
work on the live app I just removed the Subst and did a Net Use on
the drive letter. Granted though everyone had the same drive letter.

I recommend deploying only an mde, particularly if you have any users
with full Access installed.

It's also more difficult for an employee to steal the MDB which is the
corporations intellectual property.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

I don't see how using UNC is more efficient than drive letters.

Because a drive letter is resolved to the UNC path to be used.

It also removes any dependency in your app on someone correctly
configuring the PCs on which it runs (either local mapped drives or
a logon script that maps the drives for all PCs).

I have been deprecating mapped drives with my clients since 1998.

 

[bhicks11 via AccessMonster.com]

I use mapped drives in house because I support the network and manage the
users and apps. Works well for me. If I happened to move my app to a new
server with different naming I could map the drive to it and not have to make
any programming changes (or relink the tables). If I hard code the UNC I'll
have to modify the code (and relink the tables).

Bonnie
http://www.dataplus-svc.com

 

[David W. Fenton]

I use mapped drives in house because I support the network and
manage the users and apps. Works well for me. If I happened to
move my app to a new server with different naming I could map the
drive to it and not have to make any programming changes (or
relink the tables). If I hard code the UNC I'll have to modify
the code (and relink the tables).

Why do you have code that refers to drives?

In the same situation, I simply distribute a new front end pointing
to the UNC path of the back end on the new server.

Perhaps you are making your own problems by insisting on using
mapped drives (which is the way I see it, and why I completely avoid
them where I can -- that is, regardless of whether my client's
network is set up with mapped drives or not, I never use them in my
Access apps, and instead use UNC exclusively).

 

[bhicks11 via AccessMonster.com]

I see your point and agree its better in most circumstances. But I'm in a
small office and not distributing my apps so it works fine for us. I'm on
Novell and would find it easier to create one login script that everyone runs
to map drives rather than modifying the front end and redistributing it if I
changed a server.

Boy, you guys get passionate! I'm kidding - thanks David!

Bon

 

[PBISMaryland]

Thank you all for all of the correspondence. I was able to read through
these posts and solve my problem.