How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard. Furthermore, why would
you even continue to use Access as a backend when you have a much
superior option in SQL express?
What about as a future front-end development tool? Let's get serious.
Microsoft continues to publish numerous articles and videos on how you
can whip up a workable datagrid with only a few lines of code (so much
for the argument for the RAD development tool). Bring XML and the
countless advantages of the disconnected dataset architecture in .NET
and I am more convinced that Access will start to die out (short of
support for legacy systems).
The point is not to start a riot but rather seek valid arguments on how
Access will fair in the future. Thanks in advance for your input.
Jason
37  5172 
Hopefully you will get several divergent views from this exersise in
crystal-ball gazing.
Specifics in-line.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
<ja*****@bigriver.net> wrote in message
news:11**********************@38g2000cwa.googlegro ups.com... How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard.
It does look as if Microsoft is emphasizing the role of Access as desktop
database, and putting in lots of effort to make it as usable as possible for
non-programmers. But they have taken away nothing from developers, and
actually given us several useful things as well.
Furthermore, why would
you even continue to use Access as a backend when you have a much
superior option in SQL express?
Nothing else is as simple as just copying an MDB and running it on a
computer. I work mostly with small business and not-for-profit groups who
have no IT staff let alone DBMAs. Nothing else is as simple and appropriate
for them. And nothing else works as well and seamlessly as the integrated
Access (JET storage.)
What about as a future front-end development tool? Let's get serious.
Microsoft continues to publish numerous articles and videos on how you
can whip up a workable datagrid with only a few lines of code (so much
for the argument for the RAD development tool). Bring XML and the
countless advantages of the disconnected dataset architecture in .NET
and I am more convinced that Access will start to die out (short of
support for legacy systems).
When something is as good as Access, it makes sense that MS and other
companies will try to make other products that have similar features. That's
great for the other tools, and it may enable them to encroach on areas
Access had exclusively, but it does not take away from Access.
The biggest limitation of Access is that the thick-client approach was never
designed to work over a slow or unstable connection. This simply means
Access is unsuitable for that market; it takes nothing away from Access's
strengths for what it was designed for. However, more and more people do
want to use their database across these kinds of connections, so the range
of scenarios where Access is suitable is narrowing.
This is a trade-off, of course. If you want to load 20 forms at once, each
with 10 subforms that each have multiple combo boxes with thousands of
records in each, you are not going to be able to achieve that over a slow
connection. So you either move away from the thick-client approach (use
something other than Access), or you give up on the slow-connection and
retain the Access flexibility, or you settle on some compromise between the
two.
Regardless of what specific choices people make on that balance question,
Access will still have a significant future both where Microsoft wants to
pitch it (desktop database) and beyond where they want it (LANs with dozens
of users and millions of records.)
It is possible that another company will create a better desktop database
one day. Unless that happens, Access will still be the best-selling database
of all time. ja*****@bigriver.net wrote: and I am more convinced that Access will start to die out (short of
support for legacy systems).
Posts to CDMA
Jan 1 2000 - May 23 2000: 85400
Jan 1 2006 - May 23 2006: 15900 (source -> Google Groups)
Perhaps, this indicates that Access started to die out several years
ago. Perhaps it simply means that other better sources of help and
discussion were found.
I do not use Access for personal projects anymore, mostly because I
want applications which can be used anywhere, on machines with minimal
software installed. I find HTAs, ASP/ADO and lately ASP.Net/ ADO.Net
better suited for this. Perhaps other developers and businesses are
similar.
Three extraneous issues have soured me on MS and Access as well. One is
the vulnerability of MS products in general to attack. Two is VBA; the
more I try and learn other languages/scripts/technologies the more I
think that MS must bite the bullet soon and leave this anachronism
behind. Three is the travesty that are ADPs, this great dream that led
us on, failed and seem now to be passé.
If I were younger I think I would be trying to leave the MS world
entirely.
I agree, Lyle. Another point worth mentioning is the built-in
deployment features of Visual Studio where the application can
automatically check for and download updates via a web server or a
central network location. Sure, there are issues with SQL express
where you have to be carefully of overwriting the data, but you can
write code for this by attaching the database as a resource rather than
a project file. Sure beats updating Access front-ends.
<ja*****@bigriver.net> wrote in message
news:11**********************@38g2000cwa.googlegro ups.com... How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard.
MS is in business to make as much money as they can and if that means
pandering to the masses then that's what they'll do.
2p included.
Keith. www.keithwilby.com
<ja*****@bigriver.net> schrieb im Newsbeitrag
news:11**********************@38g2000cwa.googlegro ups.com... How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard. Furthermore, why would
you even continue to use Access as a backend when you have a much
superior option in SQL express?
There is no one and only DBS, DBMS or frontend. Specific problems need
specific software. Access is one great, fast and cheap tool. Some problems
need hierarchical DBMS like ADABAS, Metakit or IMS. And sometimes you need
network databases.
Some Querys are faster on Access Systems, some are faster on SQL Systems.
About frontends: If you have wireless barcode scanner with DOS Operating
System running a telnet session you can't use an Access, Foxpro, Navision or
SAP-Frontend.
So the best Software is sometimes this, sometimes that. Programming
databases is no Religion.
To get best results for your customer you have to analyze the problem first
and _after this_ to decide which is the best software.
Sorry my English isn't good enough
Rainer Franke
"Rainer Franke" <ra****@nurfuerspam.de> wrote in message
news:e4*************@news.t-online.com...
Sorry my English isn't good enough
I couldn't see anything wrong with it! :-)
Keith.
Per ja*****@bigriver.net: seek valid arguments on how
Access will fair in the future
I've been doing MS Access for over 10 years now.
My view of what I provide to the user is:
---------------------------------------------------------
1) Moment-to-moment user control over the development
effort. i.e. I can turn on a dime and make changes
very quickly.
2) Lower cost of development by a factor of at least
three (compared to VB6) and probably much more
compared to .NET.
---------------------------------------------------------
I think that in the past, I've supposed too much significance
for item #2 and not enough to item #1 - in the user's mind.
After being on the fringes of a major .NET project (IT was
replacing a 7-year-old MS Access app that I wrote) I came away
thinking that maybe I should spend some time and develop
a clonable .NET shell that I could use as a starting point
in future projects - instead of MS Access.
Never managed to do that - too many MS Access jobs and not
enough waking hours - but I still suspect it might be an
alternative RAD scenario. OTOH, that project that I just
alluded to had burned through 23 million dollars when I
checked on it last year.
The product was just delivered on May 5th.
My application - which lasted 7 years and which the users
were still happy with - came in at less than $225,000.
To me, the two biggest downsides of MS Access applications
are:
--------------------------------------------------------
- Widespread contempt among IT people for MS Access - usually
because they don't understand the distinction between
Access as a front-end development tool and a back end.
- The specter of future releases breaking an app. In a
big shop, IT rolls out the latest-and-greatest version
of MS Office and my apps are dead in the water until somebody
performs some maintenance work.
--------------------------------------------------------
--
PeteCresswell
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:44**********************@per-qv1-newsreader-01.iinet.net.au: It does look as if Microsoft is emphasizing the role of Access as
desktop database, and putting in lots of effort to make it as
usable as possible for non-programmers. But they have taken away
nothing from developers, and actually given us several useful
things as well.
It seems to me that much of the new design is aimed at FileMaker
Pro. The only things that are lacking, seems to me, is a server
version of Jet (to match FileMaker's ability to run from the server)
and ease of web distribution. The former will never happen (it would
be a SQL Server killer), and the latter is probably not possible
without major architectural changes (e.g., if forms and reports were
stored as HTML+CSS they could easily be ported to the web as long as
there was some kind of data connector that could be switched in to
replace Access in interfacing with Jet).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"(PeteCresswell)" <x@y.Invalid> wrote in
news:9d********************************@4ax.com: To me, the two biggest downsides of MS Access applications
are:
--------------------------------------------------------
- Widespread contempt among IT people for MS Access - usually
because they don't understand the distinction between
Access as a front-end development tool and a back end.
I would add to that the fact that they have no comprehension of how
Jet works and so don't understand how to deploy it in a fashion that
is safe.
- The specter of future releases breaking an app. In a
big shop, IT rolls out the latest-and-greatest version
of MS Office and my apps are dead in the water until somebody
performs some maintenance work.
--------------------------------------------------------
This is because IT (and users) think of an MDB file as a document,
like a Word document, rather than as an application. The same IT
shop would not upgrade the version of ASP or PHP or Cold Fusion that
is running their web applications without testing, but they do it to
Access. The reason for that is that they don't understand that
Access is the same as ASP/PHP/CF in regards to deployment.
That doesn't mean there aren't deployment problems with Access that
are vexing, but it does seem to come down to it that most of the
downsides of Access are due to IT ignorance.
What a surprise.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/ ja*****@bigriver.net wrote in
news:11**********************@j73g2000cwa.googlegr oups.com: Another point worth mentioning is the built-in
deployment features of Visual Studio where the application can
automatically check for and download updates via a web server or a
central network location.
I've never understood the attraction of automatic updates. I think
they are phenomenally dangerous and turn them off in every program
that offers them (including Windows Update, the most dangerous of
them all, since a failure could disable your computer entirely).
This would be no attraction to me at all.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com: Posts to CDMA
Jan 1 2000 - May 23 2000: 85400
Jan 1 2006 - May 23 2006: 15900 (source -> Google Groups)
Perhaps, this indicates that Access started to die out several
years ago. Perhaps it simply means that other better sources of
help and discussion were found.
Usenet is dying. A different newsgroup that I post in, that I've
been involved in for longer than CDMA and that has been around on
Usenet since 1985, has dropped even more precipitously in number of
posts.
I don't think anyone (other than Rudoph Giuliani fans) would
seriously suggest that the drop in that newsgroup is due to
decreasing interest in MS Access.
Thus, I really don't think you can say anything about the relative
size of the Access user/programmer population based on posts on
Usenet. Most Internet users don't know anything about Usenet.
I would also add that it seems to me that there are new groups of
users coming to Access. There have been a lot of "newbie" posts
lately from people who are starting out writing unbound forms. That
suggests to me that Access is now attracting a certain number of
programmers from other backgrounds, since they have the chops to put
together unbound forms, but lack the understanding of Access that
should tell them that they are wasting their time writing unbound
forms.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
David W. Fenton wrote: ja*****@bigriver.net wrote in
news:11**********************@j73g2000cwa.googlegr oups.com:
Another point worth mentioning is the built-in
deployment features of Visual Studio where the application can
automatically check for and download updates via a web server or a
central network location.
I've never understood the attraction of automatic updates. I think
they are phenomenally dangerous and turn them off in every program
that offers them (including Windows Update, the most dangerous of
them all, since a failure could disable your computer entirely).
This would be no attraction to me at all.
It depends on the context. You (the developer) bring Me (a business) an
update. That transaction need not be automatic and could pose the problems
you suggest if it were.
Now, the front end of that update needs to be distributed to 100 users in my
company. THAT update is better if automatic and in many cases needs to be
forced i.e. if you aren't on the latest version your app doesn't run at all.
There are certainly cases where allowing an older version to continue
running would cause real problems.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
David W. Fenton wrote: "Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com:
Posts to CDMA
Jan 1 2000 - May 23 2000: 85400
Jan 1 2006 - May 23 2006: 15900 (source -> Google Groups)
Perhaps, this indicates that Access started to die out several
years ago. Perhaps it simply means that other better sources of
help and discussion were found.
Usenet is dying. A different newsgroup that I post in, that I've
been involved in for longer than CDMA and that has been around on
Usenet since 1985, has dropped even more precipitously in number of
posts.
I don't think anyone (other than Rudoph Giuliani fans) would
seriously suggest that the drop in that newsgroup is due to
decreasing interest in MS Access.
Thus, I really don't think you can say anything about the relative
size of the Access user/programmer population based on posts on
Usenet. Most Internet users don't know anything about Usenet.
[snip]
Also if a higher percentage of users do what they should in Newsnet which is
to lurk and search before posting questions you could see a real drop in
posting activity without there necessarily being a corresponding drop in
"usage" of the group.
In a perfect world, groups targeted at beginner and intermediate levels
would eventually have very few new postings and would simply become "useful
archives".
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Rick Brandt wrote: Also if a higher percentage of users do what they should in Newsnet which is
to lurk and search before posting questions you could see a real drop in
posting activity without there necessarily being a corresponding drop in
"usage" of the group.
I can vouch for this from personal experience. I don't post questions
in this ng at all. I can assure you it is not because I have never
had a question. It's because I have never had a question I could not
find an answer to with a little effort. God bless lazy people and
those with looming deadlines.
Good question huh? -:). I agree a lot with Allen Browne and others on
good points. I think Access is becoming more robust for programmers
also. Because I do most of the development myself I use wizard,
add-ins, etc to make my job a lot easier. Most companies may start to
build application with Access but will still rely on programmers to
enhance or finish the project. Access is light weight portable and not
least affordable for most companies. Developing Access Pages is going
to be cutting edge working with primary interop assemblies (PIAs) that
contain the official description of the most commonly used., InfoPath
and other office products. I find that Access Pages don't have the
same versatility as static form, but hopefully from the same
environment access pages can be created with little bit more flex. I
seen snapshot of what Microsoft has shown of Access 2007, and
demonstration of what can be create through couple of the wizard. I
think Access will allow its developers to create application they only
thought of before. I am going to be died hard co-visionary of Access.
-:)
I have to concur with Pete's comments, because I was one of those IT
people holding Access in contempt for many years (I also put Filemaker
Pro in that category). However, a year ago I was assigned to a
significant and intense Access project, and the experience really
opened my eyes. My biggest contempt, as it turns out, was not Access,
but the misuse of Access. As Allen mentioned, many users seem to
insist that Access is a good choice for access across the network and
web by large user populations, but the application just isn't designed
for the number of users typically hitting a website database. I think
the newsgroup posting numbers more likely reflect what Rick stated,
more users, even new ones, are searching for the answers before they
post the same question. The main reason I even come to this newsgroup
is looking for information to assist me in my development. If I happen
to also find a post from someone else that offers me the chance to put
in my relevant two cents, bonus!
MS Access will survive, because it is a pretty reliable product with a
strong developer base. Even when VBA is finally revamped, which I was
told by an MS programmer from Redmond (granted he worked on SQL Server
2005), was happening with the next version of Office (not sure if it
actually happened), developers will adapt. If we couldn't handle the
changes MS throws at us, we wouldn't be very successful in this
business. :-)
Now, if MS would just unbundle Access from Office, maybe it could be
treated with more respect!
- GH
ja*****@bigriver.net wrote: How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard. Furthermore, why would
you even continue to use Access as a backend when you have a much
superior option in SQL express?
Access is going to do just fine. Tiny applications work just great in
Access, especially for people that know Excel already (and they seem to
find Access friendlier). If I had a few thousand measurement stations
across the planet with their latitude and longitude and if I wanted a
client to sort, develop reports etc., I would make a decent Access
backend/frontend with a switchboard and thats it. One mdb file, a
little functionality, looks good and can be put on a floppy (who uses
them though?) and taken places.
What about as a future front-end development tool? Let's get serious.
Serious stuffs - better work with a real RDBMS. Access is not a
complete RDBMS. I have heard good things about SQL Express but I will
give it a few more months of testing before depending on it.
MySQL/Postgres are free and good. Front-end - depends on platform and
application. Simple stuffs on Windows - VB(.NET) or C#, Web -
..NET/Java, Linux - Gtk/Pl/Java. I believe .NET/Java will do good in
front-end development on desktop or the web.
Microsoft continues to publish numerous articles and videos on how you
can whip up a workable datagrid with only a few lines of code (so much
for the argument for the RAD development tool). Bring XML and the
countless advantages of the disconnected dataset architecture in .NET
and I am more convinced that Access will start to die out (short of
support for legacy systems).
I'd still use Access for tiny applications. Access 97 is still used by
quite a few. I use 2000 now and then. Who cares about 2003 if our
frontend can handle both databases?
The point is not to start a riot but rather seek valid arguments on how
Access will fair in the future. Thanks in advance for your input.
I agree with you on the fact that it is worth thinking what will happen
to Access. When I first saw MySQL, I wondered what Access will do. It
still is strong today. Some people are using Access so extensively that
they cannot even think of moving out of it. They like it (and its
surprising to see how stable Access can sometimes be...1GB database
files are doing just fine on my 1GB RAM machine). No matter how good
SQL Express or OSS products are, there are lots of tiny developments on
Access. My belief is Access isnt going anywhere.
Chirag Shukla.
GH wrote: ...
MS Access will survive, because it is a pretty reliable product with a
strong developer base. Even when VBA is finally revamped, which I was
told by an MS programmer from Redmond (granted he worked on SQL Server
2005), was happening with the next version of Office (not sure if it
actually happened), developers will adapt. If we couldn't handle the
changes MS throws at us, we wouldn't be very successful in this
business. :-)
That's an interesting perspective. What really grieves me about .NET
is that I agree essentially with its basic premises and philosophy. I
only mourn the loss of RAD. Perhaps, we, as Access developers are
really cheating by not convincing companies to convert the RAD "demos"
they see in Access into .NET. Personally, taking three times as long
to produce a given application is not an easy sell. This (triple the
time) may change in the future, but when all the facts are laid out,
the companies I deal with usually want to use Access until that
situation changes.
I have up to 76 simultaneous users on an administrative network and an
additional 40 or so users that connect to Access in an area common to
all. The thought of going to forms bound to linked tables, even when
restricting the recordsource to a single record, is unthinkable for me.
Access on Samba under Linux worked about three times faster than any
other combination one company tried. They spent about $100,000 on new
high speed switches, networking components and a new Active Directory
server system and still could not come close to Samba running on a $400
VIA with the old networking equipment. I.e., it took two to three
times as long to access data. To be fair, using AD on linux using LDAP
instead of using windows validation might have slowed data retrieval
also, but I suspect that the LDAP delay would be much less than with
the new system given past performance. Plus, Access on Samba did not
cause a single error. The networking guy got a serious black eye
trying to outperform linux. They spent another $50,000 for a different
server system and now I see corruption issues where there were
absolutely none before. So now, if MS wags them too hard they might
dump MS and Access instead of linux, but they love Access and will
stick with MS if they don't get jerked around too much.
Although linux has come a long way, I think MS has not capitalized on
the old school compiling that has to be done under linux. I have
compiled a lot of unix code in the past so I was prepared for playing
with source files to get Samba to install the way I wanted. Even so,
it was quite an annoyance, but the license costs for Windows server
creates a lot of room for tolerance.
Finally, I still think MS is moving away from VBA. One blog entry
talked about locked-down systems where VBA is turned off completely.
I'm seriously looking at C#, XSLT and the new XML editing tools for
dealing with the XML output of Access 12 rather than relying on custom
VBA to change the XML that is produced. I still have a long way to go
in viewing the PDC 05 videos, but I don't think my perception of MS
moving away from VBA is going to change after I'm done viewing them.
It seems to me that Access is going to survive by being changed into
something else. Except for the new false concept of what RAD is, I
actually welcome the changes.
James A. Fortune CD********@FortuneJames.com
Per CD********@FortuneJames.com: Personally, taking three times as long
to produce a given application is not an easy sell. This (triple the
time) may change in the future, but when all the facts are laid out,
the companies I deal with usually want to use Access until that
situation changes.
I'd say three times for VB6... and some have countered with 5-6.
Watching a large .NET project where I used to work, I'd venture 10x minimum for
..NET.... maybe up to 20.
--
PeteCresswell
"(PeteCresswell)" <x@y.Invalid> wrote Watching a large .NET project where I
used to work, I'd venture 10x minimum
for .NET.... maybe up to 20.
If you've ever attended a DotNet user group meeting and watched the speaker
flick through screen after screen of code, you may note that much of it will
be procedures that contain just one line of code. Even if those are
automatically generated, that's pretty inefficient coding.
I am convinced that many of those "uppity object-oriented developers who
sneer at VBA because it isn't O-O" not only don't understand Access and VBA
well enough to use them properly but also don't understand their own chosen
software tools well enough to use them properly.
That's always been the case since I got into the computer business in 1958,
no matter what the tool-set being used. There are some really good
developers who get the job done with the tools at hand, and can apply their
hard-earned development skills to the next set of tools and move right
along; and there will be others who just, at best, struggle along, and
who'll have a hard time changing tool sets.
Larry Linson
Microsoft Access MVP
Larry Linson wrote: "(PeteCresswell)" <x@y.Invalid> wrote
> Watching a large .NET project where I
> used to work, I'd venture 10x minimum
> for .NET.... maybe up to 20.
If you've ever attended a DotNet user group meeting and watched the speaker
flick through screen after screen of code, you may note that much of it will
be procedures that contain just one line of code. Even if those are
automatically generated, that's pretty inefficient coding.
I am convinced that many of those "uppity object-oriented developers who
sneer at VBA because it isn't O-O" not only don't understand Access and VBA
well enough to use them properly but also don't understand their own chosen
software tools well enough to use them properly.
That's always been the case since I got into the computer business in 1958,
no matter what the tool-set being used. There are some really good
developers who get the job done with the tools at hand, and can apply their
hard-earned development skills to the next set of tools and move right
along; and there will be others who just, at best, struggle along, and
who'll have a hard time changing tool sets.
Larry Linson
Microsoft Access MVP
You and Pete make some good points here. I don't think it would be any
higher than six times for me, but I'm an optimist :-). My first
introduction to Visual C++ was with version 1.0 so I had to use
Microsoft Foundation Class (MFC) a lot. I am also allowing for more
code re-use than with VBA, but abstracting code for re-use takes extra
time also. I'll go with eight times then. Final answer. I need to do
some experimenting. I'd hate to underbid a job by an order of
magnitude because I got spoiled by Access. I wonder if what companies
that use DotNet will resort to if they get impatient with its
development costs. How many times slower will a fully competent DotNet
programmer be than an Access programmer for a job of typical
complexity?
James A. Fortune CD********@FortuneJames.com
<CD********@FortuneJames.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...
<snip> Finally, I still think MS is moving away from VBA. One blog entry
talked about locked-down systems where VBA is turned off completely.
I'm seriously looking at C#, XSLT and the new XML editing tools for
dealing with the XML output of Access 12 rather than relying on custom
VBA to change the XML that is produced.
Office 2003 can be installed w/o VBA. However, if VBA is not installed,
Access 2003 can not be installed. So, at least for now, VBA and Access are
tightly married ... one can not exist without the other.
Microsoft added the ability to exclude VBA to relieve corporate concerns
about security. However, they don't recommend it and they state:
"It is recommended that you not turn off VBA. Instead, you should use the
security features of Office to limit the potential for malicious attacks to
computer hardware or software." http://office.microsoft.com/en-au/as...403131033.aspx
VBA is an excellent development language for Microsoft Access. I can't see
any advantages in using a strong OOP tool with Access.
Steven
Steve wrote: <CD********@FortuneJames.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...
<snip> Finally, I still think MS is moving away from VBA. One blog entry
talked about locked-down systems where VBA is turned off completely.
I'm seriously looking at C#, XSLT and the new XML editing tools for
dealing with the XML output of Access 12 rather than relying on custom
VBA to change the XML that is produced.
Office 2003 can be installed w/o VBA. However, if VBA is not installed,
Access 2003 can not be installed. So, at least for now, VBA and Access are
tightly married ... one can not exist without the other.
Microsoft added the ability to exclude VBA to relieve corporate concerns
about security. However, they don't recommend it and they state:
"It is recommended that you not turn off VBA. Instead, you should use the
security features of Office to limit the potential for malicious attacks to
computer hardware or software."
http://office.microsoft.com/en-au/as...403131033.aspx
VBA is an excellent development language for Microsoft Access. I can't see
any advantages in using a strong OOP tool with Access.
Steven
Steven,
Thanks for the link. I was unaware of MS' recommendation. I certainly
did not mean to suggest that VBA is not immensely useful. I just
haven't gotten my brain around how MS is going to make VBA play nicely
with everything else. I will be very impressed if MS integrates VBA
well. I don't consider that a trivial undertaking. Perhaps that's
easier than it looks. I'm not even sure why I'm concerned about how
VBA will fit in. Maybe my concerns will disappear as I learn more.
I'd love to continue to rely on VBA as my primary means to customize
Access. I like OOP, but I won't go the OOP route unless I discover a
problem with VBA.
James A. Fortune CD********@FortuneJames.com
"Steve" <st***@nospam.net> wrote in news:nQ*************@fe10.lga: Microsoft added the ability to exclude VBA to relieve corporate
concerns about security.
This is similar to Microsoft's "sour grapes" strategy on email
attachments when they first addressed the issue of executable
content in their email clients. Instead of doing something sensible,
such as checking what the executable content of the attachment
actually attempted to do and giving the user an informative choice,
they just made all attachments inaccessible in SR2 of Outlook 2000.
This was a Draconian approach to the problem, and one that looked
petulant to anyone who had any understanding of the problem space.
I'm also reminded of the ADP situation, where for no good reason
whatsoever, Microsoft created an Access project format that doesn't
use Jet, just so they could say there's an Access project format
that doesn't use Jet (even though there's actually nothing
inherently wrong with Jet under any circumstances; and you end up
trading Jet's assumptions about what data you want for ADO's
assumptions about which data you want, and ADO is no better at
guessing than Jet was).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
It's even worse for email attachments. By default, in Outlook 2003, Access
attachments (MDB, MDE) are hidden from users.
Steven
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1... "Steve" <st***@nospam.net> wrote in news:nQ*************@fe10.lga:
Microsoft added the ability to exclude VBA to relieve corporate
concerns about security.
This is similar to Microsoft's "sour grapes" strategy on email
attachments when they first addressed the issue of executable
content in their email clients. Instead of doing something sensible,
such as checking what the executable content of the attachment
actually attempted to do and giving the user an informative choice,
they just made all attachments inaccessible in SR2 of Outlook 2000.
This was a Draconian approach to the problem, and one that looked
petulant to anyone who had any understanding of the problem space.
I'm also reminded of the ADP situation, where for no good reason
whatsoever, Microsoft created an Access project format that doesn't
use Jet, just so they could say there's an Access project format
that doesn't use Jet (even though there's actually nothing
inherently wrong with Jet under any circumstances; and you end up
trading Jet's assumptions about what data you want for ADO's
assumptions about which data you want, and ADO is no better at
guessing than Jet was).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Access will always be the king of Rapid Application development at the
desktop level. There is no desktop level language for Rapid Application
development more powerful than VBA (at the desktop level). And in
keeping with the tradition of RAD, nothing can beat VB.Net at the
Enterprise level. There is nothing faster for RAD in OOP Enterprise
development than VB.Net.
Example: you can create a VB.Net form with several textboses,
comboboxes with all events attached (using AddressOF delegates) and a
datagrid that stretches with the form in a matter of minutes. The
equivalent in Access would be an Access form with a subform (the
datagrid). But you can't stretch a subform with a form (this is where
OOP has the edge). The stretching of a datagrid is the equivalent of
stretching a table or query in Access - but you have to expose the
table/query in Access which would defeat the idea of a front end app.
My point is this: the basic form/subform textboxes/comboboxes would
take maybe 60 seconds to whip up in Access with a few user limitations
(like stretching/not server based and a few other things), thus desktop
level - but definitely Rapid Application Development. The same app
would take a few minutes in VB.Net, but you are at the Enterprise level
now. In C# or Java it would take a little bit longer. Yes, you can do
a little more fine tuning in C#/Java, but that is no longer RAD. For
OOP RAD, you can't beat VB.Net. For desktop RAD, Access is the fastest
gun in the west (and the east, south, north, the moon, mars, ...).
Filemaker pro will never match Access in desktop RAD. And even though
it has some enterprise level capabilities, I don't believe Filemaker is
going to make a very big dent in the Enterprise market. I don't think
it will even match Lotus Notes.
As long as there are desktops, I am pretty sure Access will be here for
the long haul.
Rich
*** Sent via Developersdex http://www.developersdex.com ***
Rich P wrote: As long as there are desktops, I am pretty sure Access will be here for
the long haul.
Rich
Me too! Same as Foxbase and Clipper. They are SO COOL!
"Rich P" <rp*****@aol.com> wrote As long as there are desktops, I am pretty
sure Access will be here for the long haul.
That will depend on The Boys and Girls in Redmond not changing Access beyond
recognition. Some have said they are making a good start in that direction
with Access 2007. I do know that their target is not to make, nor keep,
Access a good developer tool; it is to make it a good casual-user through
power-user tool _for the Enterprise market_.
We can only hope that the changes they feel necessary for their chosen
marketplace will not make it unusable for development for smaller customer
organizations.
My suggestion: any developer who wants to stick with Microsoft development
tools, and hasn't already, had best take a good look at DotNet and try to
figure out how best to develop for your own client set, which may be much
smaller organizations than Microsoft's target market. If you do, then you
will at least have a headstart if some set of circumstances makes Access
unusable, or unavailable.
Larry Linson
Microsoft Access MVP
"Larry Linson" <bo*****@localhost.not> wrote in message
news:Gnxeg.10107$lN5.3892@trnddc04... "Rich P" <rp*****@aol.com> wrote
As long as there are desktops, I am pretty
sure Access will be here for the long haul.
I do know that their target is not to make, nor keep, Access a good
developer tool; it is to make it a good casual-user through power-user
tool _for the Enterprise market_.
<snip>
According to Clint Covington (Lead Program Manager on the Access team),
they want to make Access 2007 easier for the end-user, more managable for
IT, and easier for the developer. http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
I don't get the impression from reading the transcript that Microsoft does
not want to keep Access a good developer's tool.
Since you "know that their target is not to make, nor keep, Access a good
developer tool" -- how do you know? Have you used the beta? What would
make an Access MVP state that Microsoft does not want to keep Access a good
developer's tool?
Steven
Steve wrote: What would
make an Access MVP state that Microsoft does not want to keep Access a good
developer's tool?
Brains?
"Steve" <st***@nospam.net> wrote What would make an Access
MVP state that Microsoft does not want
to keep Access a good developer's tool?
Steven
Steve Santus? Trolling for an argument? Go find one somewhere else.
I said what their target _is_ -- end-users in the Enterprise environment.
You err in what you attribute to me.
Larry Linson
This is what you said. I do know that their target is not to make, nor keep, Access a good
developer tool; it is to make it a good casual-user through power-user
tool _for the Enterprise market_.
There is no attempt to start an argument. Your statement is clear, and my
question is what made you draw this conclusion. Microsoft is saying that
they want to make it an *easier* development tool. You claim that their
target is not to make, nor keep, it as a good developer tool. Is easier
not good?
Steve (not Santus)
"Larry Linson" <bo*****@localhost.not> wrote in message
news:nf3fg.2414$hv1.2208@trnddc01... "Steve" <st***@nospam.net> wrote
What would make an Access
MVP state that Microsoft does not want
to keep Access a good developer's tool?
Steven
Steve Santus? Trolling for an argument? Go find one somewhere else.
I said what their target _is_ -- end-users in the Enterprise environment.
You err in what you attribute to me.
Larry Linson
What features does Access 2007 have that makes it a less desirable
developer's tool? Or is this just another bash Access thread?
"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@38g2000cwa.googlegro ups.com... Steve wrote:
What would
make an Access MVP state that Microsoft does not want to keep Access a
good
developer's tool?
Brains?
Steve wrote: "Larry Linson" <bo*****@localhost.not> wrote in message
news:Gnxeg.10107$lN5.3892@trnddc04... "Rich P" <rp*****@aol.com> wrote
As long as there are desktops, I am pretty
sure Access will be here for the long haul.
I do know that their target is not to make, nor keep, Access a good
developer tool; it is to make it a good casual-user through power-user
tool _for the Enterprise market_.
<snip>
According to Clint Covington (Lead Program Manager on the Access team),
they want to make Access 2007 easier for the end-user, more managable for
IT, and easier for the developer.
http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
I don't get the impression from reading the transcript that Microsoft does
not want to keep Access a good developer's tool.
You're making a carefully worded distinction. MS wants Access to be a
good developer's tool, but possibly in a way that doesn't include VBA.From that article I see MS trying to apply things that they put in for
end users as being for developers. Developers don't get much credit
for including features that Access does by default. I think our gain
will be the indirect one from Access becoming more popular. I can't
fault MS for listening to end users. The extra capability of reports
to drill down is nice, but mostly those developers who were
contemplating those features already will save any development time. I
suppose we will leverage those features into our designs. The ribbon
is a nice thing for developers to think about using. It's not earth
shattering. The templates are not going to save me much time either.
They might create new business when frustrated business users reach the
end of their rope.
MS seems to think that the new flexibility of the reports cover just
about anything the user could possibly want. Their customers are quite
different than mine. I think report flexibility is a good thing. I
don't think MS ignored Access developers. They tried to accomodate us
to some extent. The 'developer' mantra was simply towards DotNet
developers :-).
About the only point of the article related to developers that got
emphasized was that developers will have it easier because we won't
have to write as much VBA code. It's like telling the chef that he can
do more because more of the food will be pre-made. Developers thrive
on what Access can't do. If we can extend Access into doing things it
has never done before, everyone wins. Customers who desire
customization -- and there are lots of them -- make the developer world
go 'round. There are so many customers like that that even all the new
functionality shouldn't bother us. It doesn't bother me.
My concern is still that MS may be trying to put VBA into legacy mode.
If that happens, so that developers are forced into the DotNet world,
there will be a tremendous loss of efficiency for developers unless new
techniques for customization are developed. I suspect that the new XML
tools may be meant to lessen the hit of leaving VBA behind. MS may be
ready to put VBA on a pedestal and place a spotlight on it as the
development tool of the future. Who knows? I don't see it that way
yet. I'm seeing VBA as being a potential sacrifice to DotNet web
integration. I am going to take Larry's advice seriously and try to be
prepared for any eventuality. Maybe the PDC 05 didn't talk about VBA
much because it wasn't in yet. I'm still leaning toward the deliberate
de-emphasis theory. Maybe Access will be dumbed down via a VBA
lobotomy in the future. It doesn't make sense for MS to push VBA
anymore. Besides, some XSLT, C#, and SOAP are good for the soul until
we find out how MS really intends to do RAD.
I haven't used the beta, but I suspect that things have not gotten much
simpler for the developer. I await the praise of the beta testers to
dispel that idea.
James A. Fortune CD********@FortuneJames.com
Hi, Steve. I don't get the impression from reading the transcript that Microsoft does
not want to keep Access a good developer's tool.
Clint made it very clear that the focus is on Excel users' ease of use and
the integration of Sharepoint Services into an organization's data
management system. The expense of Sharepoint Services is going to relegate
it to the companies who can afford it, mainly the ones who create enterprise
level applications to facilitate better data management across multiple
geographical locations. While Clint didn't come out and say that Microsoft
doesn't want Access to be a developer's tool, Microsoft's focus is pushing
the product forward for the targeted customers at the expense of some of the
RAD functionality that Access developers have come to depend upon.
Clint also made a number of statements that infer that Access 2007 isn't
really targeted as a developer's tool, but more of an end user's tool. For
example, Access developers should "just start typing like they do in Excel,"
and "we want to make the product much easier to approach and discover and
learn how you can create applications without necessarily having to take a
book or study a class on how to use Access," and "make it easier for
developers in removing the need for code" (this last part is in his demo
video, not the transcript).
I don't know about you, but if I hadn't taken the time to study a good
portion of a 1,275 page book first, my first Access database application
would have been utter crapola. These people who want to "just start typing
like they do in Excel" without bothering to learn anything about relational
databases or Microsoft Access have no business calling themselves Access
developers, or being considered as such. They're Access users, a class of
people who use the Access application designed and built by someone who
knows what he's doing. If they want to become Access developers themselves,
then they'll have to put some effort into learning how to do it. That means
books, training, or significant experience through trial and error.
The market is alread flooded with people who call themselves Access
developers because they know how to use the built-in Wizards to create forms
and reports and can easily dazzle computer-challenged managers and small
company owners and convince these folks that they're competent Access
developers, or even experts. We really don't need more Excel users passing
themselves off as Access developers, too, by reasoning that they can use
Access 2007 to build unnormalized spreadsheets without having to take the
extra step to import the spreadsheet into an Access table.
And while I applaud some of the new features that make learning about
Access's features and developing an Access 2007 database application easier
and quicker with better built-in features than previous versions (the new
report designer, split forms, and the pop-up menus to filter form text box
controls come to mind), there are a good number of things that don't belong
in a relational database or in a software developers' IDE. For example:
1.) Multi-valued fields such as Attachments and Lookup Fields shouldn't be
in a relational DBMS, but Excel users think these are good ideas, and
there's no convincing them otherwise. Obviously, they haven't discovered
the problems with these items, particularly with queries. I don't need to
repeat the list of the evils of Lookup Fields, but the Attachment field is a
new one that requires a lot of manual input and maneuvering, or else code to
do what a simple UPDATE or INSERT query should be able to handle. But the
Access developer can always write VBA code that adds/deletes/changes
attachments to records, even though Clint stated Microsoft's intention was
to make it easier for developers by removing the need to write code.
2.) Bad defaults such as Track Name Autocorrect, subdatasheets, Allow Zero
Length String, et cetera. (It might also still have Option Explicit off by
default, but I don't know because I uninstalled Office 2003 from a computer
to load Office 2007 beta on it, and my former 2003 VB Editor custom settings
were used when I opened Access 2007 beta. Perhaps someone else did a clean
install and can remark on this.)
And the new UI ribbon allows for discovery of Access's features, as Clint
put it, but the additional text displayed on many of the buttons leaves no
room for some of the traditional CommandBar buttons. The missing buttons
are ones developers would deem useful, not the end users. Some other
features that are still available require more mouse clicks to accomplish
the task than in previous versions, because they aren't buttons located on
the UI ribbon. These also tend to be developer features, not end user
features. To alleviate this partial vacuum, one can add commonly used
buttons to the Quick Access Toolbar to bring back the easy access to
functionality from previous versions, but the problems with this are
three-fold:
1.) There's only one Quick Access Toolbar, so only a finite number of
buttons will show.
2.) All the buttons show no matter which view the active object is in, so
regardless of whether or not a toolbar button can be used in the current
view, it's taking up space on the toolbar. Being able to add multiple
toolbars, some for Design View, some for Datasheet View, et cetera, and
allowing the developer to control which toolbars are displayed, and when,
would give developers far more flexibility.
3.) No custom buttons can be added to the Quick Access Toolbar. (Unless
I've missed this item in the selection box.)
The UI ribbon is rather inflexible compared to the CommandBar buttons of
previous versions of Access in that one cannot drag-n-drop buttons or
sections without, you guessed it, writing code to customize the UI ribbon.
If additional custom buttons are needed on the UI ribbon, then XML code
needs to be written to allow for this custom functionality. And the fact
that it's XML code, not VBA code or simple macros, required to do the UI
ribbon customization is going to put a damper on many current Access
developers' speed of development until they become proficient in XML (or can
copy/paste someone else's code).
If this is Microsoft's idea of making it easier for developers, then our
definitions of "developer" differ by a wide margin. Microsoft's idea seems
to be more along the lines of an Excel user who can develop an Access
application from templates and built-in Wizards as a go-between for a data
source (whatever it may be) and Excel spreadsheets that analyze that data.
My idea of a developer is someone who understands relational databases,
knows how to avoid data anomolies, and can design a relational schema that
safeguards the data, and build queries, forms and reports to display, input
and edit the data, and write code to automate any processes or customize the
displays. You know. Someone competent with Access.
As for Clint's remark that Microsoft's intention is to "make it easier for
developers in removing the need for code," code is the most powerful tool
Access developers have to customize an application in ways that the built-in
features are incapable of doing, so de-emphasizing code writing is telling
me that Microsoft's beliefs are that "Access 2007 pretty much has everything
our end users need."
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"Steve" <st***@nospam.net> wrote in message
news:4b***************@fe09.lga...
"Larry Linson" <bo*****@localhost.not> wrote in message
news:Gnxeg.10107$lN5.3892@trnddc04... "Rich P" <rp*****@aol.com> wrote
> As long as there are desktops, I am pretty
> sure Access will be here for the long haul.
I do know that their target is not to make, nor keep, Access a good
developer tool; it is to make it a good casual-user through power-user
tool _for the Enterprise market_.
<snip>
According to Clint Covington (Lead Program Manager on the Access team),
they want to make Access 2007 easier for the end-user, more managable for
IT, and easier for the developer.
http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
I don't get the impression from reading the transcript that Microsoft does
not want to keep Access a good developer's tool.
Since you "know that their target is not to make, nor keep, Access a good
developer tool" -- how do you know? Have you used the beta? What would
make an Access MVP state that Microsoft does not want to keep Access a
good developer's tool?
Steven
Interesting observations.
I don't think adding features to replace a need for VBA code is bad for
developers. This has been the general trend of all RAD development tools.
The fact that there may be more people calling them Access developers who
have no idea how to develop application is bad for Access developers, and is
a risk in making Access more end-user friendly.
But then, you have Excel, which is a tool used by ordinary users, power
users, and full hard core developers. I have seen some pretty
sophisticated reporting and front end applications developed using Excel.
Access is, and will be, no different.
Regarding killing VBA, again, look at the Excel world. You have developers
using VB.Net to interface with Excel, and eventually, you will see more of
this in Access. It may come to a point that Access will run without VBA
being installed (which is true for Excel now). But I doubt that you will
see the end of VBA for many, many years given the amount of VBA code that is
running now.
As an aside, at this stage of my career, my goal is not to write VBA code,
but to solve client problems.
Steven
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM> wrote in
message news:VO********************@adelphia.com... Hi, Steve.
I don't get the impression from reading the transcript that Microsoft
does not want to keep Access a good developer's tool.
Clint made it very clear that the focus is on Excel users' ease of use and
the integration of Sharepoint Services into an organization's data
management system. The expense of Sharepoint Services is going to
relegate it to the companies who can afford it, mainly the ones who create
enterprise level applications to facilitate better data management across
multiple geographical locations. While Clint didn't come out and say that
Microsoft doesn't want Access to be a developer's tool, Microsoft's focus
is pushing the product forward for the targeted customers at the expense
of some of the RAD functionality that Access developers have come to
depend upon.
Clint also made a number of statements that infer that Access 2007 isn't
really targeted as a developer's tool, but more of an end user's tool.
For example, Access developers should "just start typing like they do in
Excel," and "we want to make the product much easier to approach and
discover and learn how you can create applications without necessarily
having to take a book or study a class on how to use Access," and "make it
easier for developers in removing the need for code" (this last part is in
his demo video, not the transcript).
I don't know about you, but if I hadn't taken the time to study a good
portion of a 1,275 page book first, my first Access database application
would have been utter crapola. These people who want to "just start
typing like they do in Excel" without bothering to learn anything about
relational databases or Microsoft Access have no business calling
themselves Access developers, or being considered as such. They're Access
users, a class of people who use the Access application designed and built
by someone who knows what he's doing. If they want to become Access
developers themselves, then they'll have to put some effort into learning
how to do it. That means books, training, or significant experience
through trial and error.
The market is alread flooded with people who call themselves Access
developers because they know how to use the built-in Wizards to create
forms and reports and can easily dazzle computer-challenged managers and
small company owners and convince these folks that they're competent
Access developers, or even experts. We really don't need more Excel users
passing themselves off as Access developers, too, by reasoning that they
can use Access 2007 to build unnormalized spreadsheets without having to
take the extra step to import the spreadsheet into an Access table.
And while I applaud some of the new features that make learning about
Access's features and developing an Access 2007 database application
easier and quicker with better built-in features than previous versions
(the new report designer, split forms, and the pop-up menus to filter form
text box controls come to mind), there are a good number of things that
don't belong in a relational database or in a software developers' IDE.
For example:
1.) Multi-valued fields such as Attachments and Lookup Fields shouldn't
be in a relational DBMS, but Excel users think these are good ideas, and
there's no convincing them otherwise. Obviously, they haven't discovered
the problems with these items, particularly with queries. I don't need to
repeat the list of the evils of Lookup Fields, but the Attachment field is
a new one that requires a lot of manual input and maneuvering, or else
code to do what a simple UPDATE or INSERT query should be able to handle.
But the Access developer can always write VBA code that
adds/deletes/changes attachments to records, even though Clint stated
Microsoft's intention was to make it easier for developers by removing the
need to write code.
2.) Bad defaults such as Track Name Autocorrect, subdatasheets, Allow
Zero Length String, et cetera. (It might also still have Option Explicit
off by default, but I don't know because I uninstalled Office 2003 from a
computer to load Office 2007 beta on it, and my former 2003 VB Editor
custom settings were used when I opened Access 2007 beta. Perhaps someone
else did a clean install and can remark on this.)
And the new UI ribbon allows for discovery of Access's features, as Clint
put it, but the additional text displayed on many of the buttons leaves no
room for some of the traditional CommandBar buttons. The missing buttons
are ones developers would deem useful, not the end users. Some other
features that are still available require more mouse clicks to accomplish
the task than in previous versions, because they aren't buttons located on
the UI ribbon. These also tend to be developer features, not end user
features. To alleviate this partial vacuum, one can add commonly used
buttons to the Quick Access Toolbar to bring back the easy access to
functionality from previous versions, but the problems with this are
three-fold:
1.) There's only one Quick Access Toolbar, so only a finite number of
buttons will show.
2.) All the buttons show no matter which view the active object is in, so
regardless of whether or not a toolbar button can be used in the current
view, it's taking up space on the toolbar. Being able to add multiple
toolbars, some for Design View, some for Datasheet View, et cetera, and
allowing the developer to control which toolbars are displayed, and when,
would give developers far more flexibility.
3.) No custom buttons can be added to the Quick Access Toolbar. (Unless
I've missed this item in the selection box.)
The UI ribbon is rather inflexible compared to the CommandBar buttons of
previous versions of Access in that one cannot drag-n-drop buttons or
sections without, you guessed it, writing code to customize the UI ribbon.
If additional custom buttons are needed on the UI ribbon, then XML code
needs to be written to allow for this custom functionality. And the fact
that it's XML code, not VBA code or simple macros, required to do the UI
ribbon customization is going to put a damper on many current Access
developers' speed of development until they become proficient in XML (or
can copy/paste someone else's code).
If this is Microsoft's idea of making it easier for developers, then our
definitions of "developer" differ by a wide margin. Microsoft's idea
seems to be more along the lines of an Excel user who can develop an
Access application from templates and built-in Wizards as a go-between for
a data source (whatever it may be) and Excel spreadsheets that analyze
that data. My idea of a developer is someone who understands relational
databases, knows how to avoid data anomolies, and can design a relational
schema that safeguards the data, and build queries, forms and reports to
display, input and edit the data, and write code to automate any processes
or customize the displays. You know. Someone competent with Access.
As for Clint's remark that Microsoft's intention is to "make it easier for
developers in removing the need for code," code is the most powerful tool
Access developers have to customize an application in ways that the
built-in features are incapable of doing, so de-emphasizing code writing
is telling me that Microsoft's beliefs are that "Access 2007 pretty much
has everything our end users need."
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"Steve" <st***@nospam.net> wrote in message
news:4b***************@fe09.lga...
"Larry Linson" <bo*****@localhost.not> wrote in message
news:Gnxeg.10107$lN5.3892@trnddc04... "Rich P" <rp*****@aol.com> wrote
> As long as there are desktops, I am pretty
> sure Access will be here for the long haul.
I do know that their target is not to make, nor keep, Access a good
developer tool; it is to make it a good casual-user through power-user
tool _for the Enterprise market_.
<snip>
According to Clint Covington (Lead Program Manager on the Access team),
they want to make Access 2007 easier for the end-user, more managable for
IT, and easier for the developer.
http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
I don't get the impression from reading the transcript that Microsoft
does not want to keep Access a good developer's tool.
Since you "know that their target is not to make, nor keep, Access a good
developer tool" -- how do you know? Have you used the beta? What
would make an Access MVP state that Microsoft does not want to keep
Access a good developer's tool?
Steven
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:VO********************@adelphia.com: As for Clint's remark that Microsoft's intention is to "make it
easier for developers in removing the need for code," code is the
most powerful tool Access developers have to customize an
application in ways that the built-in features are incapable of
doing, so de-emphasizing code writing is telling me that
Microsoft's beliefs are that "Access 2007 pretty much has
everything our end users need."
Microsoft's marketing has pretty much always demonstrated a complete
lack of understanding of the developer side of Access, seems to me.
Despite that fact, the Access team itself seems to me to have
understood the developer side, since Access has lots of
opportunities for the kind of developer you describe to get things
done.
The way I see it is that Access has lost a lot of mindshare to
FileMaker Pro in ease of use for end users. The result of this is
the rise in the number of FileMaker developers, and a narrowing of
the market for Access developers.
So, to me, the emphasis on end users in Access 2007 is a *good*
thing, as it means Access will again be competitive on ease of use,
which means people will be using it, which means they'll be cocking
things up and needing to hire someone like me to fix it.
More end user capability = more developer projects.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Allen |
last post by:
Hi all,
Will my pointer survive this conversion?
MyType_tag MyType;
MyType_tag* pMyPntr = &MyType;
int iUglyTempStorage = (int)pMyPntr;
MyType_tag* pMyOtherPntr =...
|
by: pw |
last post by:
Hi,
I converted (actually, imported) my Access 97 application into Access
2003. I selected "Create MDE" and it prompts me for the mde file to
create. However, what A2003 really does is create...
|
by: Welman Jordan |
last post by:
Hello all,
In Session_OnStart, I set a session variable:
Session = DateTime.Now;
and
Session.Timeout = 15;
|
by: Pravin A. Sable |
last post by:
Dear All,
I am VB programmer, from VB 3.0... to VB.6.0. I love
VB :-). I wish to move to VB.net, but I have been advised
by certain people to move to C#. They even claim that
VB.net will die down...
|
by: WannaKatana |
last post by:
I am just wondering why, with nothing else running and executing an
update query against a very large table, does Access seem to be
causing less than 10% processor usage. Then it says "There is not...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
