Publishing a form to a shared network folder

[Guest]

I'm new to Access. I created a form in Access 2003 which have check boxes
and drop down blocks and I want to place it in a folder for the rest of the
employees to fill in. How do I or can I place it in a folder? or what do I
need to do to make this form accessible to all workers? It's a request form
and I want it to work where the employee checks off the appropriate boxes and
email the form to me. I also would like to keep track of the requests and be
able to create reports, etc. from the requests I receive.

 

[Nikos Yannacopoulos]

Linda,

We need to sort out some misunderstandings here. To begin with, forms
live in Access files (MDB's or MDE's), not on their own; moreover,
form's don't store data themselves, so you can't fill in a form and
e-mail it. A form is just a user interface to a table in the database
fiel, which stores the data behind the scenes.

If you want an application for use over a LAN then the scheme this works
under is, your application is split in a Back End (tables storing the
data) stored in a shared folder on a server, and Front End (queries,
forms, reports, macros if any, code if any) linked to the Back End, a
copy of which is stored on each user's local HDD. As users fill in
forms, data is automatically stored in the back end, all in one place,
available for you to report on. No e-mails, no copying and pasting or
importing, or whatever.

The bad news starts if you need this for remote users: Access doesn't
like WANs, modem connections etc. In that case, you either need to
resort to a costly (and slower) setup like a Citrix server or Remote
Desktop or something, or you need to have your users e-mail a non-Access
form (an Excel spreadsheet?) that you will have to somehow transfer
accross, either by importing or by copying and pasting. So, if you do
have remote users, you need to evaluate the pros and cons of each
approach, taking into account the number of remote users, and the number
of forms you expect to be filled remotely. If these numbers are high,
perhaps you should look at an altogether different approach, like a
web-based app.

HTH,
Nikos

 

[Douglas J. Steele]

Forms in Access don't have a life of their own: they only exist inside an
mdb (or mde) file.

 

[Joseph Meehan]

I'm new to Access. I created a form in Access 2003 which have check
boxes and drop down blocks and I want to place it in a folder for the
rest of the employees to fill in. How do I or can I place it in a
folder? or what do I need to do to make this form accessible to all
workers? It's a request form and I want it to work where the
employee checks off the appropriate boxes and email the form to me.
I also would like to keep track of the requests and be able to create
reports, etc. from the requests I receive.

There are several possible issues so how about a little more information
so we can maybe help you avoid a pitfall or two.

How many people will access the form?

Do all these people have Access installed on their own computer?

How often will these people access the form?

Assuming they have Access installed on their personal machines you can
just copy the file to any folder on the server and then make sure everyone
has full access (read write create delete and edit) to that folder. They
can then open the database (not just the form) from their own machine.

 

[James A. Fortune]

Linda,

We need to sort out some misunderstandings here. To begin with, forms
live in Access files (MDB's or MDE's), not on their own; moreover,
form's don't store data themselves, so you can't fill in a form and
e-mail it. A form is just a user interface to a table in the database
fiel, which stores the data behind the scenes.

If you want an application for use over a LAN then the scheme this works
under is, your application is split in a Back End (tables storing the
data) stored in a shared folder on a server, and Front End (queries,
forms, reports, macros if any, code if any) linked to the Back End, a
copy of which is stored on each user's local HDD. As users fill in
forms, data is automatically stored in the back end, all in one place,
available for you to report on. No e-mails, no copying and pasting or
importing, or whatever.

The bad news starts if you need this for remote users: Access doesn't
like WANs, modem connections etc. In that case, you either need to
resort to a costly (and slower) setup like a Citrix server or Remote
Desktop or something, or you need to have your users e-mail a non-Access
form (an Excel spreadsheet?) that you will have to somehow transfer
accross, either by importing or by copying and pasting. So, if you do
have remote users, you need to evaluate the pros and cons of each
approach, taking into account the number of remote users, and the number
of forms you expect to be filled remotely. If these numbers are high,
perhaps you should look at an altogether different approach, like a
web-based app.

HTH,
Nikos

If the workers all have Access and your office is networked I suggest
keeping the data in tables in an Access "backend" mdb file stored on the
server. You can give each user a copy of a "frontend" mdb file stored
on their C: drive that has links to the Access tables on your server.
An Access Form in the "frontend" can add a new record to the table on
the server that holds requests "as if" it's right there on the user's
machine. That way you don't have to deal with the emails or with
copying and pasting data from the emails. This seems to be what Nikos
is suggesting. It takes time to get good at Access but the time is
rewarded.

James A. Fortune

 

[CAPcoordinator]

Hi James-

upon reading your post I think you may be able to answer my question. I have
an Access DB; three related Tables, and one Form I'd like to use to enter
data into two of the Tables (via a Form / SubForm setup). I would also like
to (if possible) have the Form accessible via a SharePoint site which is run
by a colleague. I am not sure how to go about setting him up (either via
SharePoint or otherwise) with just the frontend mdb file (to store on his C
drive as you say below) while (a) maintaining the backend and (b) not opening
the entire DB to data entry error from various multiple users (who, ideally,
would be entering their own data periodically).

Not sure if this question makes sense but I would appreciate hearing your
thoughts and pursuing further, if possible- thank you very much.
-Chris