more Access 07 thoughts, (censored by the Access Team Blog?)

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.

Re: more Access 07 thoughts, (censored by the Access Team Blog?)

On Nov 9, 10:06 am, g...@walla.co.il wrote:
> 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.

Well, I think one major reason is that the software app developed
under Access will be bulky and hog memory and resources. Another
reason, this is just a guess, is that the software you developed might
not work after the user installs a newer (or maybe even a later)
version of Access. (You will have to test that one.) Also, the
programming interface isn't as robust as Visual Studio. So that is
just the personal preference of the programmer. You also have to
consider the type of application being developed. Should you do a
graphics editing program with Access? No. (Not that you could not,
but why would you use a DBMS development environment to create such an
app?) Should you do a CD or MP3 file catalog application with
Access? Yeah. You can.

Don't get me wrong - I'm not telling you that you're a blistering
id10T for wanting to create shareware apps with Access. I don't know
what you've developed so I can't tell you what to do. The bottom line
is: if it works for your users and their happy with it - good for
you.

Re: more Access 07 thoughts, (censored by the Access Team Blog?)

On Nov 9, 1:06 pm, g...@walla.co.il wrote:

These are just some idle thoughts that may or may not be pertinent.
1. Access is a very strange beast. An Access application can, and
often does, mix data, logic and interface all in the same file. Is
there another such application?
2. All or almost all COM applications require dynamic link library
functions to do their work, usually implicitly, but sometimes
explicitly when we declare API functions. But Access goes far beyond
that. It requires the mantra of the Access executable. An Access
application is more dependent than other applications which require
only dynamic link library, type libraries or frameworks. To me, this
disqualifies Access as a suitable platform on which to build share-
ware or shrink-wrap programs.
3. Microsoft, which can drive me mad from time to time, can be
enormously generous in making available extremely powerful
technologies that are scalable and can be used on almost any platform,
and not-so-modern machines. These include ADO, HTA, WSF, VBScript and
JScript, all enhanced with ActiveX and all one hundred per cent free.
Recently I wrote an HTA application which mines disorganized data from
an Excel spreadsheet, organizes and modifies it, and transports it to
an MS-SQL Database that exists more than 4000 kilometers from here.
Total size of the file is 17 kb, and yet it has a pretty and useful
interface, and accomplishes a task it took several persons day to do
in about twenty seconds. When I completed the application, I faced
Redmond, took my hat off and said, "I can't imagine how you are making
money from making these technologies available to me for free. Perhaps
you are, but the method is not upfront, staring me in the face."
Regardless, I do know that I am making money from them; perhaps as
important is my feeling of accomplishment and the inner glow I have
when my client says, "Oh My! You mean I just click that button and
it's all DONE! You're amazing!" I suppose I should tell her that it's
actually Microsoft that is so amazing.
4. Access has allowed many persons who are not programmers, not
mathematicians, not logical, indeed, not educated to think of and to
call themselves "Developers" and/or "Programmers". Access cannot make
a silk purse out of a sow's ear, and many such persons who have little
idea of what they are actually doing, will forever be dissatisfied.

Re: more Access 07 thoughts, (censored by the Access Team Blog?)

Thanks for the replies.
If my post above gives the impression that I am "forever dissatisfied"
as lyle commented, then I would like to try and correct that
impression. I too am very grateful for the tremendous achievements and
advancements that Microsoft has brought upon the world. I think that
Access is absolutely great and do not take if for granted. I actually
also clearly mentioned that in the original message that I tried to
post in the Access Blog, but left it out here because I wanted to try
to shorten it a little. I now see I shouldn't have left it out. I just
hope that as Access is continually developed it will become easier to
use as a platform for shareware programs, and I hope that this will
not be impossible. I believe that this can be achieved but that it
requires the right priorities from those who develop it.