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.
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.
<jas...@bigriver.net> wrote in message
> 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
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.
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
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
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.
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
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
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
I couldn't see anything wrong with it! :-)
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
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
- 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.
> 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).
> To me, the two biggest downsides of MS Access applications
> - 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
> - 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.
> 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.
> 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
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
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
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
> 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.
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
Now, if MS would just unbundle Access from Office, maybe it could be
treated with more respect!
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
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
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.
> 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.
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
James A. Fortune
> 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."
VBA is an excellent development language for Microsoft Access. I can't see
any advantages in using a strong OOP tool with Access.
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
> 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" <XXXu...@dfenton.com.invalid> wrote in message
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.
*** Sent via Developersdex http://www.developersdex.com ***
> As long as there are desktops, I am pretty sure Access will be here for
> the long haul.
Me too! Same as Foxbase and Clipper. They are SO COOL!
> 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
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.
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.
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
> What would
> make an Access MVP state that Microsoft does not want to keep Access a good
> developer's tool?
> What would make an Access
> MVP state that Microsoft does not want
> to keep Access a good developer's tool?
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.
> 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
Steve (not Santus)
"Larry Linson" <bou...@localhost.not> wrote in message
"Lyle Fairfield" <lylefa...@aim.com> wrote in message
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
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
> 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
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."
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/expert_contributors2.html for contact
"Steve" <st...@nospam.net> wrote in message
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
As an aside, at this stage of my career, my goal is not to write VBA code,
but to solve client problems.
"'69 Camaro" <ForwardZERO_SP...@Spameater.orgZERO_SPAM> wrote in
> 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
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.