Rob,
If everyone is on the company network, the way to handle this is with a split database. An mdb file (backend) with just the tables
goes on a server and then everyone gets a copy of an mdb file (front-end) with everything else, the forms, reports, queries, etc.
The front-ends are all linked to the backend. If you have a good solid network, this approach will usually support 10 to 20 users
depending on how heavily the system is used.
The downside of this approach is that everyone must have a copy of Access installed or you will need to create an Access run-time to
install using the Office Developer Edition (ODE.) The ODE gives you the run-time files and more importantly, a license to distribute
them.
If you want to go the browser route, you might look into Data Access Pages (DAPs.) I personally don't like them because they are a
poor substitute for an Access form. I usually bite the bullet and write Active Server Pages (ASPs.) You do need a web server on the
network for ASPs.
To get an idea of the tradeoffs, start searching for the different technologies in the Knowledge Base at
http://support.microsoft.com/default.aspx?scid=FH;EN-US;KBHOWTO and on MSDN at
http://msdn.microsoft.com/library/default.asp.
No mater which direction you go, you're going to have a learning curve.
Personally, if everyone is on the network, I'd go the split database route. I've been using it successfully for years. You might
have a few up front $s if you need to get the ODE. However, the learning curve to make run-times will be much shorter than learning
to make DAPs or ASPs, ending up being faster develop and thus less $s in the long run.
I wish you luck.
--
Sco
M.L. "Sco" Scofield, MCSD, MCP, MSS, Access MVP, A+
Useful Metric Conversion #15 of 19: 5 dialogues = 1 decalogue
Miscellaneous Access and VB "stuff" at
www.ScoBiz.com