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" <ForwardZERO_SPAM.To.69Camaro@Spameater.orgZERO_SP AM> wrote in
message news:VOGdnd305eGFvODZ4p2dnA@adelphia.com...[color=blue]
> Hi, Steve.
>[color=green]
>> I don't get the impression from reading the transcript that Microsoft
>> does not want to keep Access a good developer's tool.[/color]
>
> 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" <steve@nospam.net> wrote in message
> news:4bNeg.374$XB5.266@fe09.lga...[color=green]
>>
>> "Larry Linson" <bouncer@localhost.not> wrote in message
>> news:Gnxeg.10107$lN5.3892@trnddc04...[color=darkred]
>>> "Rich P" <rpng123@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_.
>>>[/color]
>>
>> <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
>>
>>
>>[/color]
>
>[/color]
