Oh, by the way, the front-end is distributed as an .mde or .accde. Both
hide the built-in toolbars/ribbons and are limited to using the
toolbar/ribbon that were created for each of them
--
Karen
Although currently a one-user application, it would also make sense to
develop a means to let an entire
office use the application. The user front-end would talk to a SQL
Server backend.
If only about 2-10 users in the same office will be using the appliation,
then you'll likely not need to deploy and use SQL server in this situation.
Do I use the developer tools to develop the installation package or
migrate to InstallShield or Wise
The first question I would ask right now is have you been in issuing the
many bug fixes, updates, and satisfying the many requests that those people
have for new reports, or even modifying a report?
Other issues of wide distribution might require you to add the ability to
display the company name or particular branding information for that one
organization on the each report. (and perhaps you might wanna add a button
to your reports menu bar that allows you to be mail or send the particular
document your viewing as a pdf file). Once again only you can answer these
types of questions.
Another issue is things like defaults in forms. I have a form with setup
information for the particular company (name, address etc). I also have a
form that allows me to setup the defaults for things like State/Province and
city. Thus when the person enters a new record, the default city field is
"their" city, not the one I choose during development. Same goes for the
area code default, and state/province default. What I'm suggesting here is
for you to look at any of the values in your application that you perhaps
hard coded inside of the code, or have placed inside of the forms design
mode for defaults. This issue may or may not matter for your application,
but you want to sit down and give it some thought in terms of how these
things work now.
What this means is you want advoid hard coding some of the defaults in MS
access (forms, or tables). You also have to assuem it is unreasonable to
think that you're end users are going to be able to modify the code in the
system that you're deploying.
What this also means is that you likely using a split database right? If
your application is not split, then how have you been issuing the many bug
fixes, updates etc. for new features? So, how have you been updating these
people software now? I should point out that no installer tool will solve
this problem for you, and you have to have some design considerations in
your application to allow you to issue a bug fixes and updates to your
software in the field. This usually means your application has to be split.
I cannot stress how important it is to come up with a system to manage the
updating of this software on users machines you never seen. Furthermore it
sounds like you have some experience with the application being deployed in
the field right now. Note that with wider distribution you will have to
address the issues like different screen sizes (screen resolution), and also
things like different kinds of printers (about the only advice I can mention
with different kinds of printers is to make sure that you been very liberal
with your margins in your reports.
The other issue is to you plan to deploy the application on machines without
an actual copy of a MS access installed? If that's the case, then you'll
want to consider using the runtime package and deployment system that is
available for MS access. Note that these runtime systems do not have a means
to update and maintain your software in the field for you. However, the
runtime system does allow you to build a standard windows install that will
allow you to create a CD, or even a web download in which users can install
the software.
If you're going to distribute to machines that you've never used before, or
machines that have a very large variety of different versions of office,
then you're going to have a lot of problems in this regards. The reason for
this is a MS access does not play well when other versions of MS access are
already installed on the particular target computer. If this is the case,
then you have to do two things:
1) heed the above advice about making some means of updating your software
in the field.
2) If you're going to be looking at wide distribution on machines that you
don't know what version of office they have, then you have to come up with a
fairly robust and independent install of the MS access that will not damage
or interfere with the existing versions of office, or even MS access.
Installing multiple versions of MS access on the same machine tends to be
quite problematic. As a general rule I can to avoid this type of setup
altogether.
However if I was going to widely distribute to a lot of different machines,
and reduce the problems of support and installing the software, then I would
recommend you purchase some install scripts for the runtime deplopyment
system for MS access (the ones that come with ms-access package system are
NOT up to quality for commercial distribution of your application).
You can find install scripts here:
www.sagekey.com
Where do I look for deployment specialists who are familiar with Access
applications?
How difficult it is to deploy your application is going to depend on how
well it's been designed now, and what you done so far to issue updates. Keep
in mind the issue of installing the application, and the issue of updating
new updates for bug fixes are not always one and the same thing.
The other issue of course is to do you want to install the application on
machines that don't necessarily have a version of the MS access installed?
Once again the amount of work to do this is going to be based on how much
effort and time you've put into the application now. For example do you hide
all in the additional menus and options you see in the MS access interface?
After all it might be too much that you require the users to go out and be
trained on how to use MS access. So, if you hide all things like the query
builder, and report writer from their prying eyes you make the application
far more user friendly and easy to use. For example, I don't allow my users
to see any of the query builder or any of the internals of my applications.
Take a quick read of the following as to how I allow users to to enter
things like date ranges and other parameters for report's:
http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html
Another issue is have you design the user interface well enough to reduce
the training costs of people using this application? I give some hints and
thoughts on building a user interface that reduces your training costs by
substantial amounts here:
http://www.members.shaw.ca/AlbertKallal//Articles/UseAbility/UserFriendly.htm
If not the newsgroups then how do I find those 'experts' who know how to
take the next step? The newsgroups are great but I'm up for finding the
right 'experts' to contract with; just have no idea where to look
As mentioned if you are looking to purchase some deployment technologies,
sagekey is a good starting point. However the issues we'll need the most
work is to ensure that you've built and designed your system that reduces
training costs, should hide the MS access interface, should be split, should
likely allow you to deploy to users without MS access, and have designed a
means to update both the application part (front end), and the table
structures in the back end of your system by users you'll never meet in
person.
I know many of you have developed robust applications, what is the next
step?
As mentioned start by answering some of the questions above like do have you
run a split system? I talk about running a split database in the following
article of mine:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Of course one thing always leads to the next step, and once you've learned
to split your database, then I'm sure you'll have cobbled together some code
to automatically re-link the front end to the back end. Same code is here:
http://www.mvps.org/access/tables/tbl0009.h
How much work all of the above steps are really depends on how you've done
things now. For example to use the MS access runtime, you have to build and
provide your own menu system and interface. Since in all of my applications
I've always hidden the built in access menus, then deployment using the
runtime for me was no extra work at all. However if you've not been hiding
the MS access interface in your example appcation, then you have to address
this issue, Especially if you plan to use the runtime. (and of course if you
hide most of the MS access interface, then new users who will not be
overwhelmed with all kinds of menu options and features that they really
don't need to use).
