Allowing other users to launch my app

[David Portwood]

If it were a shared Excel workbook that I had created, I would simply copy
and paste that workbook onto a shared network drive. Leaving aside security
matters for the moment, with Access is it still a matter of locating my .mdb
file on my local drive and then copying and pasting it onto a shared network
drive? And then anybody with a copy of Access will be able to open it?

 

[Arvin Meyer [MVP]]

Not quite. With Access, you need to split the database into a data only
(tables) database which will be placed on a share on the server, and the
front-end linked to it that has all the other objects and code. The
front-end must reside on each user's workstation.

While Excel locks the entire file, Access has the ability to lock only the
page of records that each user is editing so that multiple users can work at
the same time.

Anyone with a copy of Access, and the front-end, and who has permissions on
the share on the server can open the database. You can further secure it
with a password or user-level security in versions before 2007.

 

[David Portwood]

Wait a minute. "With Access, you need to split the database..."? I
understand that there are advantages to doing so, but my app would still
work if I didn't, right? It would still allow data entry from multiple
users?

I'm using Access 2000.

 

[Douglas J. Steele]

Yes, it would still work, but the chance of database corruption would be
significantly higher, and it would generate much more network traffic.

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)

 

[Joseph Meehan]

If it were a shared Excel workbook that I had created, I would simply
copy and paste that workbook onto a shared network drive. Leaving
aside security matters for the moment, with Access is it still a
matter of locating my .mdb file on my local drive and then copying
and pasting it onto a shared network drive? And then anybody with a
copy of Access will be able to open it?

While I greatly respect Avin and I agree that you should really do as he
says. It will save you a lot of possible problems later, it is not
absolutely necessary.

A common problem with trying to share Access files is the fact that most
people don't have Access loaded on their machine. It is not part of the
home or business versions of Microsoft Office, it is part of the Office
Professional suite however and can be purchased separately. Without the
program on their machine, they can't use it.

There is a way of providing them with a limited copy of Access. If you
have the developer's version of Access (I forget what the current versions
of it is called) it comes with a special read and edit, but not make or
design version of Access that you can legally give to users of your product.

 

[John W. Vinson]

There is a way of providing them with a limited copy of Access. If you
have the developer's version of Access (I forget what the current versions
of it is called) it comes with a special read and edit, but not make or
design version of Access that you can legally give to users of your product.

TonyToews keeps a record:

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

John W. Vinson [MVP]

 

[Arvin Meyer [MVP]]

Sorry Joseph,

No matter which version of Access you use, the only time you should ever use
an unsplit database is when you are the only user and are running it from a
standalone workstation. Even if you are the only user on a server, you
should split the database to reduce the chance of corruption. Even when
using a Terminal Server, you should split the database and put a copy of the
front-end in a folder for each user.

 

[Arvin Meyer [MVP]]

Will it work? Yes. Will it corrupt? Should a packet drop, there is a
reasonable chance of corrupting a front-end. I've not had to deal with data
corruption in more than 4 years now. I did have a form corruption about a
year ago, but that was a development problem with 1 machine. I attribute the
good luck to always using quality equipment and always splitting the
database.

Don't worry. Splitting is incredibly easy, so easy that I've never bothered
using the wizard. But there is a wizard that will walk you through doing it
in a few minutes.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[Joseph Meehan]

Sorry Joseph,

No matter which version of Access you use, the only time you should
ever use an unsplit database is when you are the only user and are
running it from a standalone workstation. Even if you are the only
user on a server, you should split the database to reduce the chance
of corruption. Even when using a Terminal Server, you should split
the database and put a copy of the front-end in a folder for each
user.

And I agree. The only difference is SHOULD or MUST. "you need to"
sounds like "must" to me. Maybe that is just me. I would say that should
may be an understatement.

 

[David Portwood]

I understand that I should split the database and I will eventually do so. I
don't plan to do it right now because:

1. I'm not sure how to distribute the front end to users who have Access on
their local drives. Apparently this is possible and there are some freeware
programs to help me do it. But I need to look into the matter a little more.

2. The design of my app is still in a state of some flux but it can be used
as is and it is urgently needed.

3. I'm not sure how to maintain a split database. For instance, I don't know
how to relink the tables if I unlink them (don't know how to do that,
either) for maintenance.

Rest assured, I don't doubt the benefits of splitting the database and I
will do so just as quickly as I can. In the meantime I must deploy the
unsplit app. Time is critical. I will designate maintenance periods - after
3:00 pm everybody out of the database! - during which time I will
incorporate any and all fixes for that day which I will have tested on a
separate copy.

 

[John W. Vinson]

I understand that I should split the database and I will eventually do so. I
don't plan to do it right now because:

1. I'm not sure how to distribute the front end to users who have Access on
their local drives. Apparently this is possible and there are some freeware
programs to help me do it. But I need to look into the matter a little more.

Tony Toews' Auto Front End Update: http://www.granite.ab.ca/access/autofe.htm
is very simple to use, very efficient and easy to use.

2. The design of my app is still in a state of some flux but it can be used
as is and it is urgently needed.

If you're updating the application AND users are using it then I'd say that
splitting is *required*. A user will get an error message when they attempt to
open a form that you're working on - *IF* you're both lucky. They may get an
irretrievably corrupted database instead.

3. I'm not sure how to maintain a split database. For instance, I don't know
how to relink the tables if I unlink them (don't know how to do that,
either) for maintenance.

If you link to the \\server\path\database.mdb format, using Network
Neighborhood to do the linking, then you don't NEED to relink unless you
change the table structure itself. If you do, do the relinking in your new
frontend and let Tony's update distribute it!

Rest assured, I don't doubt the benefits of splitting the database and I
will do so just as quickly as I can. In the meantime I must deploy the
unsplit app. Time is critical. I will designate maintenance periods - after
3:00 pm everybody out of the database! - during which time I will
incorporate any and all fixes for that day which I will have tested on a
separate copy.

Good luck. Sometimes investing a little time now will save a lot of time
later.

John W. Vinson [MVP]

 

[aaron.kempf]

Access is a pain in the ass

your friends will get prompted 3 times when they open it; I reccomend
using Access Data Projects so that your database has a FUTURE

it's a lot simpler, plug and play- without any of the headache of
linked table CRAP

 

[aaron.kempf]

this is wrong

It is not part of the
home or business versions of Microsoft Office,

 

[aaron.kempf]

gosh--

if you wanted to prevent corruption you would use ADP and not link

linking is for babies; and it brings referential integrity problems
into the mix

 

[aaron.kempf]

correction

the only time you should use a SPLIT database is when you're a ****ing
retard blue-head that can't learn the new version of Access


with ADP linking and all this crap is not necessary
plug and play- all your tables and queries live in one place

 

[Arvin Meyer [MVP]]

Answers in line:

I understand that I should split the database and I will eventually do so.
I don't plan to do it right now because:

1. I'm not sure how to distribute the front end to users who have Access
on their local drives. Apparently this is possible and there are some
freeware programs to help me do it. But I need to look into the matter a
little more.

The easiest way is to place a copy of the front-end, already linked, on the
server, and have each user simply copy it to their workstation.

2. The design of my app is still in a state of some flux but it can be
used as is and it is urgently needed.

All the more reason to split it. You can work on a copy while the other
users are in production, then place your copy on the server to replace the
production copy. Users then simply copy the new one, replacing their own, or
use one of the utilities such as Starter:

http://www.datastrat.com/Download/Starter.zip

or:

AutoFE Updater:
http://www.granite.ab.ca/access/autofe.htm

to do it for you.

3. I'm not sure how to maintain a split database. For instance, I don't
know how to relink the tables if I unlink them (don't know how to do that,
either) for maintenance.

You never need to unlink them for maintenance. If you need to refresh the
links:

Tools >>> Database Utilities>>> Link Table Manager

Rest assured, I don't doubt the benefits of splitting the database and I
will do so just as quickly as I can. In the meantime I must deploy the
unsplit app. Time is critical. I will designate maintenance periods -
after 3:00 pm everybody out of the database! - during which time I will
incorporate any and all fixes for that day which I will have tested on a
separate copy.

And how do you resolve all the data entry between the 2 versions? You have
the new front-end and the server has the correct data. OOPS! big problem.
Split database: No problem. You can link your development front-end to the
production back-end, but I would think it safer to link to a test back-end,
then use the Link Table Manager to link to the production back end, and move
a copy of the front-end to the server.

 

[aaron.kempf]

splitting is a pain in the ass

and it's not necessary

having a 3-tier database architecture; chock full of MDB is a total
waste of time

use Access Data Projects and stfu kids

 

[aaron.kempf]

im sorry

because his database 'is in flux' it is better to have frontend
backend?

why so that he can be constantly relinking refreshing?

MDB sucks balls it is a losing paradigm

keep everything in Access Data Projects and stop trying to get newbies
to install your SPYWARE 'auto fe updater'