lyle fairfield wrote:
Many developers do almost none of the above, with the exception of
splitting their applications.
I am one of them.
Hmmm...raises an interesting point for discussion. Seems that at the
very least I'd want to deploy the application with some kind of failsafe
mechanism, so that if the back end data file got moved, the front end
had some reasonably elegant way of restoring the links without requiring
developer intervention. At the most, it would require 1 minute of time
from a system administrator who knew the correct path for the backend
and could point the app there. That's probably why the Verify Links
modules have been adopted so widely. Why re-invent the wheel when it's
already out there?
As far as the other stuff goes, setting up a specific security file for
that app might make for an inconvenience for the users, since they have
to remember a separate username and password for the application. But I
can't imagine allowing users to go in and monkey around with the design
of the app. So it seems that, again at the very least, you'd want to
turn off all or most of the startup options.
Also, one other caveat. I recall seeing a lot of issues a few years back
when developers tried to deploy a split front/back database, but where
there were multiple versions of Access installed on the various
workstations, especially 97 vs. 2000. What I learned from that was that,
as a general rule, it's a good idea to migrate everybody altogether from
one version of Office to the next before deploying an application. Just
to be on the safe side.
Have you really deployed split apps with no security and no front
end/back end verification and no startup options turned off? No troubles
with that?