more Access 07 thoughts, (censored by the Access Team Blog?)
- From: gdpz@xxxxxxxxxxx
- Date: Fri, 09 Nov 2007 18:06:26 -0000
Hi,
I tried to post the following in the Access Team Blog (twice) but
didn't see it posted. I don't know if it was because it is long or
because the administrator censored it.
I did manage to get a short note published so maybe it is just the
length of the post.
I tried to post this as a comment in the 31 October 07 topic.
Here is the Blog's address:
http://blogs.msdn.com/access/default.aspx
So I will copy it here :
In the gigantic world of software, there are probably millions and
millions of freeware and shareware applications that developers and
companies have built over the years, and have distributed through the
net and through various other channels. Please correct me if I am
wrong but it is my impression that of these incalculable number of
applications, only a miniscule marginal fraction is build on the
foundations of Access. I am not referring to what you may call "in
house" or "consulter" development, where a company hires a developer
to tailor an application to their needs, so the number of times the
program is distributed to other users is relatively small.
What I am on the other hand talking about, is software that many end
users can, on their own, download and install on their personal
computers and/or local networks.
Assuming that Access is usually not the preferred development
environment for such applications (again, please correct me if I am
wrong here), I want to try and understand why these distributable
programs are usually not written in Access. Perhaps you can help me in
that quest.
Is it because Access is not as good an instrument to build
applications with?
No, I believe it probably is better then most other options for many
purposes.
Is it because it takes longer to built software with Access?
No, as a matter of fact it is probably much faster. It is said to be
three times as rapid as VB or C++ or .net etc.. and some say faster.
Is it because the user interface or the reporting is limited and the
functionality options are reduced compared to the other options?
No, as a matter of fact these are some of Access's advantages.
Is it because it was not built for the purpose of writing
distributable software in the first place? Was it built for the end
user just like the rest of the Office suit, like Word, Excel or
Outlook.
So what? This is not a good excuse. Access has what it takes to build
applications, so who cares what it was planned for. Besides, I think
that most end users do not know how to begin to take advantage of what
Access has to offer because it requires a steep learning curve. Unlike
the other office programs you really need to invest time and effort
into learning how to create applications that are more then just
another more cumbersome version of Excel. I do not consider myself to
be an authority in Access (although I do know quit a bit), but even to
reach my knowledge level, a tremendous effort was required of me, so I
can only guess what was required of those of us who are the real
experts. So the result is that if Access is left for the end users
then it is probably not used much at all. I find it hard to believe
that Microsoft would invest so much into building such a robust
application infrastructure only to have it not being used properly and
sufficiently as it actually can be.
I think I know some of the answer to this riddle but I am curious to
read if anyone has any more input on this matter to help me understand
it better. I assume the answer has to do with the issues involved in
the final steps of application development and deployment. I believe
that this final step has not been addressed properly by the Access
team over the years. This final step requires that after an
application has been tested and refined, it will be possible to pass
it on to many users, and that if upgrades are created it will be
possible to easily disseminate them to these users.
Here are some of the issues in this final step that need to be
addressed by the Access team:
If you want to package and deploy a real application you can not be
content with the free runtime extensions, so you absolutely need a
third party tool (you can not mark files as never overwrite using
these extensions, as one example of the lacking in this instrument).
Also, there are problems when the same application is distributed to
different users that have different versions of Windows or of Office,
or sometimes multiple versions of these products. There is a problem
with different users having different service packs for these
products. (As a wild solution to these problems I think it would have
been better if the runtime files would have been distributed as part
of Windows. That way at least some of these problems would have been
solved. They are free anyway so why not? And Windows gets updated
automatically). And what happens when Access is upgraded and the data
file changes format. If users have already accumulated some data in an
mdb backend file for example, you must have an easy way of allowing
them to transfer this data into the new accdb format if you want to
use it on your upgrade. All this reshuffling that happens every two or
three years, and the fact that there are many issues with cross
platform compatibilities creates a lot of instability and confusion
that deter developers of such programs that I am talking about here.
Maybe the reason for not attributing enough importance to this final
step in shareware development is because there isn't anything in it
for Microsoft to gain. What does M$ have to gain if one developer
sells some software to some other users? It is preferable to target
the end users themselves from M$ point of view, because then their
money will go directly to M$ instead of to the developer. But I have
already written above that these will be relatively few because of
Access complexity so I don't believe that this strategy will work for
Access. So think of all those developers that developed those millions
of shareware applications in a platform other then Access. They could
have used Access to develop their products. Isn't their money green?
Maybe the problem is that even if developers do select a different
platform other then Access, it will still probably be just another
Microsoft product, so the giant will not loose anything anyway, so why
bother. But then why should M$ invest in Access in the first place?
According to this logic it is best for M$ to just get rid of Access
and invest all of its resources in these other more successful
platforms.
I am at odds here. Perhaps some other people can shed some more light
on this for me.
The reason I am writing this as you may have guessed is that I have a
couple of such programs that I want to distribute. I worked very hard
in perfecting them, but this final step if deployment seems to be very
difficult and intimidating.
Thanks for reading.
.
- Follow-Ups:
- Prev by Date: Re: Creating un-aggregated tables in access
- Next by Date: Union query plus editable table
- Previous by thread: Creating un-aggregated tables in access
- Next by thread: Re: more Access 07 thoughts, (censored by the Access Team Blog?)
- Index(es):
Relevant Pages
|
