In a nut shell, you need to split this database.
You can read about splitting here:
http://www.granite.ab.ca/access/splitapp.htm
Lets go look at a few details and issues here:
I have
experienced many, many problems on the way such as missing acive x files,
fonts, and security not working.
ActiveX should not be too much of a problem. However, if you started using
acttiveX controls,t hen you WILL HAVE to setup a install process on EACH
computer. For this reason, the decision to use controls that are NOT native
to ms-access is a rather LARGE development decision. So, if you used the
calendar control, treeview control etc, then you MUST setup something to
ensure that the target machine has the SAME software.
Further, access 2000 requires a LOT of updates and patches. Again, one has
to assume that you installed all of the sp packs on your development
machine. This also includes the updates to the JET. And, before you deploy
your application, you MUST ensure that the target machines have those same
service packs and updates to JET (other wise, you are development code to a
DIFFERENT standard then what the target machines have. If those target
machines don't have the same libraries and code that your software is
relying on,then you are in effect using a DIFFERENT version of ms-access the
your users..and the results will be NOTHING but pain, and headaches. So,
make sure YOUR development machine has the latest updates, and further make
sure the target machines have the same updates). If you are starting this
process again, then I would do a de-compile before you deploy.
After I resolved the missing active x files I tried to run the program on
a
network pc and I was never asked for a password. I figured out that I
must
replace the local PC system.mdw file with the server's system.mdw file.
Then
after getting in the application, I had blank screens and file paths that
the
program said were invalid.
Coping the workgroup file to each pc is not very good idea. What happens
when you add a new user, change passwords etc? Are you going to re-deploy
the workgroup file to each station? (this is just not manageable). Worse,
you do NOT WANT TO JOIN a particular workgroup file, as then ALL ACCESS
applications will now prompt for a username+password (why torture users here
when they run other access applications?). So, the ONLY workable solution
here is to place the workgroup file on your server with your back end. Your
users then use a shortcut you created that launches the application part (on
each pc, and preferable a mde). That shortcut also includes the path name to
the workgroup file that is shared.
Thus, a shortcut might look like:
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"c:\program files\RidesXP\RidesXP.mdb"
/wrkgrp \\wserver\ridessystem\Rides.mdw
As mentioned, using a shortcut allows you to set the workgroup file, and NOT
HAVE to go to each machine, and "join" the workgroup file. You REALLY REALLY
REALLY want to leave the default workgroup file alone, and I would NOT
CHANGE it.
Anyway...split your database, deploy mde's to users, and follow the above
advice....
