[AccessD] Next Version of Access 12 Musings on what might happen (RANT)

A compiled executable only runs when the runtime is in place.  That's
just as true of VB executables as it is of anything that might be done
in Access.  Since you would still need to install the Access runtime on
a machine, what would be the point of an executable?

Charlotte Foust

-----Original Message-----
From: bruce_bruen at mlc.com.au [mailto:bruce_bruen at mlc.com.au] 
Sent: Tuesday, February 10, 2004 8:00 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Next Version of Access 12 Musings on what might
happen (RANT)

I have no doubt that the progress of desktop programming environments is
of value. As you say some functions available today were not possible in
previous times - I only have to look at the pictures of carrots on the
supermarket cash register display to remind me of that :-)

My disappointment lies in the way that Access has progressed lately and
"according to Getz" will be progressing in the future.  I use Access as
a Rapid Development IDE mainly for one off analytic work - quite
possibly this is not the mainstream use of the tool.  However, in that
realm, it is superb.  I believe, please correct me if I'm wrong guys,
that the majority of the serious business applications that generate the
revenue of many of the listers are quite right-sized by the access
model.

There is one probable exception.

I agree that Access does, and always has, run like a dog across a
network. It is also sensitive to unstable networks.  I repeat - has and
always has. Now has M$ ever adequately addressed that?  Not within the
Access model.

We have always lacked a means to generate native executables. Why? What
would be the technical difficulty in producing an Access FE compiler?

I am all for progress of Access. I just want it to be what I want and
need, which is not for development of medium to large scale commercial
applications.  When I do get involved in that it is within a technical
base that supports that level of development - as you say in Studio or
.net using a heavyweight rdbms.

B





All true, but  the issue raised was: "How many companies would still be
running DOS if they had a choice? I bet a lot, because it is the
function of the software that really matters in business, and not so
much the underlying technology."

The 'function of the software' of the many applications running today,
simple would not be capable of running under DOS due to its limitations,
hence the reason why alternatives have been designed.

I'd say that companies wouldn't really care what the underlying OS is,
as long as their apps of choice would run.  I can't see many cases at
all where an org would *choose* to run an application under DOS if they
had the choice.

This whole discussion of 'leave Access alone its not broke' is raised
whenever new versions are released.  Its unfortunate that many are
unwilling to even consider the advances that could be made.  I'd be
interested to know how many here have actually used Visual Studio and/or
programmed in .Net. If not, I don't see how you can pass judgement in
this areas on possible improvements, advances or tools that you've not
used.  (Yes, I professionally program in this environment and consider
the framework / languages and environment superior to that of the Access
IDE, which I have thoroughly enjoyed using for the past 10 years).

We work in a dynamic industry that is constantly changing. Some of us
seem to refuse to adapt or accept change and others look to the future.

Cheers,
Andrew

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com