G
Guest
I'm trying to create an application that others can use and some of them do not have MS Access. Is this possible?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
V
Victor Delgadillo
You will need the 'developer's edition' of Office, which comes with the
tools to install a runtime for Access together with the other files to run
Access independently of having or not the program installed.
As an advice, if you are talking of a few PCs (or a customer or friend's
PC), it is better they buy the full version. That way they will have all the
freedom of modifying, and even creating their own databases. The runtime is
for commercial distribution of packages where the seller does not count on
having the correct Access version on the receiving machine.
--
Victor Delgadillo MS-MVP Access
Miami, Florida
Mensajes a los grupos de noticia, asi todos nos beneficiamos!
¿Quieres saber que es un MVP?
tools to install a runtime for Access together with the other files to run
Access independently of having or not the program installed.
As an advice, if you are talking of a few PCs (or a customer or friend's
PC), it is better they buy the full version. That way they will have all the
freedom of modifying, and even creating their own databases. The runtime is
for commercial distribution of packages where the seller does not count on
having the correct Access version on the receiving machine.
--
Victor Delgadillo MS-MVP Access
Miami, Florida
Mensajes a los grupos de noticia, asi todos nos beneficiamos!
¿Quieres saber que es un MVP?
do not have MS Access. Is this possible?MTCoffers said:I'm trying to create an application that others can use and some of them
G
Guest
I have a database that I would like to run as a stand alone application as well. I am trying to decide if it would be advantageous to buy the developers edition or to find someone to package the database for me. How difficult is it to use the developers edition? If it is above the expertise of an novice to intermediate level programmer, how does one go about finding a developer to assist them in this project.
I have just found this site and have been extremely pleased with all the information I have seen over the past week. What a generous group
Thanks for the input
Mary
I have just found this site and have been extremely pleased with all the information I have seen over the past week. What a generous group
Thanks for the input
Mary
L
Larry Linson
Without more information than is convenient to include in a newsgroup post,
it would really be difficult to make that determination. One option that
might be helpful in the future would be to find a local consultant /
contractor with experience in this area to work _with_ you in packaging the
database for distribution, so you could learn as you do it.
Many find that the Developer Edition alone is not really sufficient and
invest in a third-party-installer package such as Wise InstallMaster, or
InstallShield, and the SageKey scripts. You still have to have the Developer
Edition (or for Access 2003, "Visual Studio Tools for Office 2003 System")
to have a license to distribute the runtime. (Just a caution: All together,
this can be more than a little expensive.)
Larry Linson
Microsoft Access MVP
developers edition or to find someone to package the database for me. How
difficult is it to use the developers edition? If it is above the expertise
of an novice to intermediate level programmer, how does one go about finding
a developer to assist them in this project.
it would really be difficult to make that determination. One option that
might be helpful in the future would be to find a local consultant /
contractor with experience in this area to work _with_ you in packaging the
database for distribution, so you could learn as you do it.
Many find that the Developer Edition alone is not really sufficient and
invest in a third-party-installer package such as Wise InstallMaster, or
InstallShield, and the SageKey scripts. You still have to have the Developer
Edition (or for Access 2003, "Visual Studio Tools for Office 2003 System")
to have a license to distribute the runtime. (Just a caution: All together,
this can be more than a little expensive.)
Larry Linson
Microsoft Access MVP
well. I am trying to decide if it would be advantageous to buy theMary said:I have a database that I would like to run as a stand alone application as
developers edition or to find someone to package the database for me. How
difficult is it to use the developers edition? If it is above the expertise
of an novice to intermediate level programmer, how does one go about finding
a developer to assist them in this project.
information I have seen over the past week. What a generous group!I have just found this site and have been extremely pleased with all the
A
Albert D. Kallal
It is not that hard to package the application with the runtime.
However,the real problem is that often the original database was not
designed with commercial distribution in mind. Was yours?
For example, virtually every single windows product you have ever purchased
and installed in your computer no doubt has a standard windows menu bar. The
use of a menu bar is standard use in any application. So, the next question
would be:
Did you create some nice menu bars in YOUR application? I am sure you have
already hidden the ms-access interface a long time ago...right?
I mean, if you have not yet done the above, then it would be little bit soon
to be talking about distributing an application where the ms-access
interface is NOT YET hidden, and hopefully a nice menu bar system has
already
been created. It would be much like a auto mechanic stating I am ready to
start
working on automobiles in a commercial operation, but not know that cars
need
gasoline to run! Or, a 1st year pre-med student has just dissected a his
first frog and now wants to operate on humans.
You can read the following comments as to why menus make sense in access:
(The following screen shots are from ms-access, but the comments applies to
any windows development environment that you use to write software. So,
while the following is in ms-access, it certainly does not have to be).
http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm
Further, in addition to the above common sense, the runtime system DOES NOT
supply any menu bars, and you have to make you own anyway. Often, if your
application already hides the ms-access interface, but you did not use
ANY of the built in menu bars, then you can spend 5 minutes and create a
menu bar with ONE option (ie: File-Exit). That is all you really need.
You can download and run an example of such an application at:
http://www.attcanada.net/~kallal.msn/msaccess/DownLoad.htm
Grab the 3rd one from the above url. After you play with it, hold down
the shift key during start-up to by-pass the menu options. You can now
see how I made/set those start-up options to "hide" ms-access. Oh, yes,
and you do have code to dis-able the shift-key by-pass for your application
installed...right?).
Regardless, anyone who has gotten as far as being "ready" to distribute a
commercial application would not be surprised by any of the above. If your
application is not designed this way, then you might have to ask your self
how ready is your application for commercial use? In other words, do you now
hide the ms-access interface, and provide menus? In fact, I always made
custom
menus bars for ALL of my reports (do your reports provide a menu bar?).
Further, I would bet that every single windows application your ever
purchased in addition to having nice menu bars, also has a nice help file.
Again, I would think, or even bet that your application also has a nice help
file
system...right?
Further, I am sure you are running a split mdb arrangement. That means your
front end is a mde, and the back end is a mdb file. If you are not running
a split mdb, then once again you are not near close to being ready for
"commercial" applications. Have you ever sent existing clients a update to
your existing application? How do you handle this now? (hint, there is not
difference when you use the runtime, as your application is still just a
simple mde file). So, when you fix bugs, or add new reports etc, how
do you NOW handle these updates? I mean, if you don't have basic experience
with simply updating your users now, when do you plan to get this
experience?
Thus, no doubt, I likely DO
NOT even have to ask if your application is a split mdb if you are taking
about distribution!...right?
Further, since you no doubt are running a split mdb, then I am sure you also
have your own code to check if the location of the back end has changed.
Thus
you application will now provide options to re-link the tables. So, how now
do you deal with re-linking of the front end and the back end now? Once
again,
if you don't have a working solution to re-linking, then you can't possibly
even
begin to think about distribution at this point.
I mean, any application written does not necessary need a help file, but it
certainly should have some menus, and it certainly does need some code to
provide options to re-link the tables. Of course, you have already been long
running
a split mdb so you can update bugs and code fixes with ease for your users,
right?
If any of the above concepts and ideas are not fully integrated into your
existing ms-access applications, then likely you are not ready for prime
time.
With the above exception of the menus, none of the above HAS to be done for
the runtime, but it would not make sense otherwise.
So, any seasoned access developer would not need to be told, or
do any of the above, since it would have been second nature for years. In
other words, even if you take a good access developer, and NEVER TELL them
of the existence of the runtime system, a well designed application would
take
little effort, if any at all to package and deploy it for the runtime
system.
The basic stuff like having hid the ms-access interface, and the provisions
for re-linking tables etc would have been included in your applications for
years.
So, if you are not running a split application, then you need to learn, and
get some experience in this area. And further, I would certainly have had
some test clients running the split application for a good amount of time
before
un-leasing a un-tested application on new customers. In other words, you
can't just add all of the design ideas outlined above in one shot without
first
having a good deal of test customers, and a good deal of feedback/experience
in this area over some time.
Also, do you plan to have a end user "manage", or setup security on the
application? If yes, then you should spend an afternoon writing your own
security manager. It is not hard, and that is what I did. However, I did
not just "add" in the security as an after thought, but designed the
application with using workgroup security in mind. To be fair, you don't
really need to deal with, or implement security on a product that you
distribute, but if you do use security, then yes, you must in the
runtime, you have to provide a security management system.
The other thing that you must realize that ms-access is NOT very well suited
to being installed on a pc that you DO NOT have full control over. Remember,
the runtime is simply a version of ms-access without the "design" tools, and
the menu are stripped out. However, the runtime is STILL A FULL install of
ms-access. The install size of your resulting application can be in the 80
to 150 meg install range. This large install size means that the resulting
package is ONLY suitable for downloading on high speed internet, and not
via dial-up. We are likely talking cd only distribution here.
Since the runtime is still a full ms-access install, then ALL OF THE
PROBLEMS
that you encounter when running mixed versions of ms-access on a pc still
exist.
Of course, since you been working and developing in ms-access for a long
time, then
again you have a lot of experience of running your application on pc's with
multiple versions of ms-access installed...right?
Fact is, the runtime install tools really only get a license to install
and distribute the runtime royalty free. Thus, you get the ability to
distribute your application. However, the installing scripts and tools
included
with ms-access developer ARE VERY POOR! Thus, you REALLY do need to build
your own
install scripts, or purchase them from a company that has a lot of
experience
in this area (or, you have to gain the expertise yourself, which could take
a very long time).
Microsoft had at one time 80 full time employees working JUST ON the
install routines
for Excel. I sure you have lots of testing and quality control staff on your
large team of developers also!
I don't want to scare you here. However, the problem you are dealing with is
that ms-access is usually tied to a particular version of office. If the
target pc has a different version of office, then you will run into a pile
of
problems. The solution to those problems can be fixed by purchasing a some
3rd
party installers and scripts. So, after you purchase the runtime/developer
edition of ms-access, then you can purchase some 3rd party scripts at:
www.sagekey.com
I suggest you take a nice little browse around the above site and do some
reading.
And, yes, do you have any automation code? Once again, no doubt that code
uses late binding. If you don't know what this means, then once again you
are NOT ready to distribute your software.
so, to answer you simple question of:
about finding a developer to assist them in this project.
Well, as mentioned, the amount of effort and time is going to be based on
how well your application now is setup and designed now for people who do
not
HAVE TO know ms-access. So, if you were a good developer in the first place,
then I would say very little work is required. The resulting product should
result in your users not even knowing that ms-access is needed.
So, does your current application hide the ms-access interface? What do your
currently do now to deal with reports, and what printer they go to? How do
your users re-link to the back end?
All of these questions no doubt you have
dealt with for years, and no doubt have now included solutions to these
problems for your users for a long time..right? Since any developer
would provide the above solutions,a and they would be provided by
any good developer EVEN WHEN NOT using the runtime system.
So, assuming you had much experience solving these basic problems
that every developer has to solve for a long time, then the effort
to use the runtime system to deploy your application will be
not be much work at all.
However,the real problem is that often the original database was not
designed with commercial distribution in mind. Was yours?
For example, virtually every single windows product you have ever purchased
and installed in your computer no doubt has a standard windows menu bar. The
use of a menu bar is standard use in any application. So, the next question
would be:
Did you create some nice menu bars in YOUR application? I am sure you have
already hidden the ms-access interface a long time ago...right?
I mean, if you have not yet done the above, then it would be little bit soon
to be talking about distributing an application where the ms-access
interface is NOT YET hidden, and hopefully a nice menu bar system has
already
been created. It would be much like a auto mechanic stating I am ready to
start
working on automobiles in a commercial operation, but not know that cars
need
gasoline to run! Or, a 1st year pre-med student has just dissected a his
first frog and now wants to operate on humans.
You can read the following comments as to why menus make sense in access:
(The following screen shots are from ms-access, but the comments applies to
any windows development environment that you use to write software. So,
while the following is in ms-access, it certainly does not have to be).
http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm
Further, in addition to the above common sense, the runtime system DOES NOT
supply any menu bars, and you have to make you own anyway. Often, if your
application already hides the ms-access interface, but you did not use
ANY of the built in menu bars, then you can spend 5 minutes and create a
menu bar with ONE option (ie: File-Exit). That is all you really need.
You can download and run an example of such an application at:
http://www.attcanada.net/~kallal.msn/msaccess/DownLoad.htm
Grab the 3rd one from the above url. After you play with it, hold down
the shift key during start-up to by-pass the menu options. You can now
see how I made/set those start-up options to "hide" ms-access. Oh, yes,
and you do have code to dis-able the shift-key by-pass for your application
installed...right?).
Regardless, anyone who has gotten as far as being "ready" to distribute a
commercial application would not be surprised by any of the above. If your
application is not designed this way, then you might have to ask your self
how ready is your application for commercial use? In other words, do you now
hide the ms-access interface, and provide menus? In fact, I always made
custom
menus bars for ALL of my reports (do your reports provide a menu bar?).
Further, I would bet that every single windows application your ever
purchased in addition to having nice menu bars, also has a nice help file.
Again, I would think, or even bet that your application also has a nice help
file
system...right?
Further, I am sure you are running a split mdb arrangement. That means your
front end is a mde, and the back end is a mdb file. If you are not running
a split mdb, then once again you are not near close to being ready for
"commercial" applications. Have you ever sent existing clients a update to
your existing application? How do you handle this now? (hint, there is not
difference when you use the runtime, as your application is still just a
simple mde file). So, when you fix bugs, or add new reports etc, how
do you NOW handle these updates? I mean, if you don't have basic experience
with simply updating your users now, when do you plan to get this
experience?
Thus, no doubt, I likely DO
NOT even have to ask if your application is a split mdb if you are taking
about distribution!...right?
Further, since you no doubt are running a split mdb, then I am sure you also
have your own code to check if the location of the back end has changed.
Thus
you application will now provide options to re-link the tables. So, how now
do you deal with re-linking of the front end and the back end now? Once
again,
if you don't have a working solution to re-linking, then you can't possibly
even
begin to think about distribution at this point.
I mean, any application written does not necessary need a help file, but it
certainly should have some menus, and it certainly does need some code to
provide options to re-link the tables. Of course, you have already been long
running
a split mdb so you can update bugs and code fixes with ease for your users,
right?
If any of the above concepts and ideas are not fully integrated into your
existing ms-access applications, then likely you are not ready for prime
time.
With the above exception of the menus, none of the above HAS to be done for
the runtime, but it would not make sense otherwise.
So, any seasoned access developer would not need to be told, or
do any of the above, since it would have been second nature for years. In
other words, even if you take a good access developer, and NEVER TELL them
of the existence of the runtime system, a well designed application would
take
little effort, if any at all to package and deploy it for the runtime
system.
The basic stuff like having hid the ms-access interface, and the provisions
for re-linking tables etc would have been included in your applications for
years.
So, if you are not running a split application, then you need to learn, and
get some experience in this area. And further, I would certainly have had
some test clients running the split application for a good amount of time
before
un-leasing a un-tested application on new customers. In other words, you
can't just add all of the design ideas outlined above in one shot without
first
having a good deal of test customers, and a good deal of feedback/experience
in this area over some time.
Also, do you plan to have a end user "manage", or setup security on the
application? If yes, then you should spend an afternoon writing your own
security manager. It is not hard, and that is what I did. However, I did
not just "add" in the security as an after thought, but designed the
application with using workgroup security in mind. To be fair, you don't
really need to deal with, or implement security on a product that you
distribute, but if you do use security, then yes, you must in the
runtime, you have to provide a security management system.
The other thing that you must realize that ms-access is NOT very well suited
to being installed on a pc that you DO NOT have full control over. Remember,
the runtime is simply a version of ms-access without the "design" tools, and
the menu are stripped out. However, the runtime is STILL A FULL install of
ms-access. The install size of your resulting application can be in the 80
to 150 meg install range. This large install size means that the resulting
package is ONLY suitable for downloading on high speed internet, and not
via dial-up. We are likely talking cd only distribution here.
Since the runtime is still a full ms-access install, then ALL OF THE
PROBLEMS
that you encounter when running mixed versions of ms-access on a pc still
exist.
Of course, since you been working and developing in ms-access for a long
time, then
again you have a lot of experience of running your application on pc's with
multiple versions of ms-access installed...right?
Fact is, the runtime install tools really only get a license to install
and distribute the runtime royalty free. Thus, you get the ability to
distribute your application. However, the installing scripts and tools
included
with ms-access developer ARE VERY POOR! Thus, you REALLY do need to build
your own
install scripts, or purchase them from a company that has a lot of
experience
in this area (or, you have to gain the expertise yourself, which could take
a very long time).
Microsoft had at one time 80 full time employees working JUST ON the
install routines
for Excel. I sure you have lots of testing and quality control staff on your
large team of developers also!
I don't want to scare you here. However, the problem you are dealing with is
that ms-access is usually tied to a particular version of office. If the
target pc has a different version of office, then you will run into a pile
of
problems. The solution to those problems can be fixed by purchasing a some
3rd
party installers and scripts. So, after you purchase the runtime/developer
edition of ms-access, then you can purchase some 3rd party scripts at:
www.sagekey.com
I suggest you take a nice little browse around the above site and do some
reading.
And, yes, do you have any automation code? Once again, no doubt that code
uses late binding. If you don't know what this means, then once again you
are NOT ready to distribute your software.
so, to answer you simple question of:
expertise of an novice to intermediate level programmer, how does one goHow difficult is it to use the developers edition? If it is above the
about finding a developer to assist them in this project.
Well, as mentioned, the amount of effort and time is going to be based on
how well your application now is setup and designed now for people who do
not
HAVE TO know ms-access. So, if you were a good developer in the first place,
then I would say very little work is required. The resulting product should
result in your users not even knowing that ms-access is needed.
So, does your current application hide the ms-access interface? What do your
currently do now to deal with reports, and what printer they go to? How do
your users re-link to the back end?
All of these questions no doubt you have
dealt with for years, and no doubt have now included solutions to these
problems for your users for a long time..right? Since any developer
would provide the above solutions,a and they would be provided by
any good developer EVEN WHEN NOT using the runtime system.
So, assuming you had much experience solving these basic problems
that every developer has to solve for a long time, then the effort
to use the runtime system to deploy your application will be
not be much work at all.