CDMAPoster@FortuneJames.com wrote in
news:1140473264.336191.248080@g44g2000cwa.googlegr oups.com:
[color=blue]
> David W. Fenton wrote:[color=green]
>>
CDMAPoster@FortuneJames.com wrote in
>> news:1140467379.516010.154970@g14g2000cwa.googlegr oups.com:[color=darkred]
>> > This is interesting. In spite of it being called Access 12,
>> > Microsoft is really eliminating Access and VBA. SQL Server
>> > Express for the data and .NET for the interface with
>> > definitions and reporting in XML.[/color]
>>
>> Huh? Where in the world are you getting this information? Surely
>> not from the Access 12 blog on MSDN, which has said nothing of
>> the sort.[/color]
>
> It's possible that ADO and DAO will be available in Access 12. . .[/color]
It's not only "possible" but it's what MS is promising. Access 12 is
going to be backwardly compatible. And I can't recall any statements
that it's going to introduce any form of .NET into Access.
[color=blue]
> . . . but SQL
> Server Express without VBA definitely seems to be where MS is
> heading. . .[/color]
Not for Access. I believe that you are completely misinformed. What
Access 12 is actually going to offer is a new default db engine that
is derived from (and backwardly compatible with) Jet. See:
http://blogs.msdn.com/access/archive...13/480870.aspx
[color=blue]
> I have not seen any indication anywhere that VBA will be able to
> be used in Access 12 at all. . . .[/color]
I think you've got it entirely upside-down. I have seen absolutely
no indication anywhere in the voluminous writings from Microsoft
employees about the new Access 12 that indicate an abandonment of
VBA and any significant move to .NET (except for add-ons, i.e., code
that is external to Access).
But, please, show me where on the Access blog that it says VBA is
out and .NET will replace it:
http://blogs.msdn.com/access/
[color=blue]
> . . . I may be wrong. . . .[/color]
I think you are completely mistaken. There are a lot of new features
described in this "what's new" article:
http://blogs.msdn.com/access/archive...07/490113.aspx
But not once is any change to VBA or incorporation of .NET
mentioned. I'd think that would be a major issue if it were happen,
and not something that MS would be completely silent about.
But if you have a link where an authoritative source from MS has
said that VBA is being abandoned in Access in favor of .NET, then,
please, provide the documentaiton for it.
[color=blue]
> . . . If you need to customize
> the output before or after it's created you need something like
> Visual Studio or FrontPage or something else. XML is not just
> used as a storage mechanism. If Access 12 can't create the XML
> you need, then VBA is not an option.[/color]
This is all so much fantasy. It has no basis in any reality that
Microsoft has described for Access 12.
[color=blue][color=green][color=darkred]
>> > [cliche alert] It's starting to look like they dumped the RAD
>> > baby out with the bathwater. . . .[/color]
>>
>> If your major premise is wrong, your minor premise cannot be
>> proven.[/color]
>
> That may be so, but VB.NET or C# is quite a bit slower to develop
> in than VBA.[/color]
Those are irrelevant, as THEY AREN'T GOING TO BE INCORPORATED INTO
ACCESS 12. That's what I meant by "major premise" -- the assertion
about VBA being dropped is simply WRONG, thus any comments about
relative RAD capabilities and speed are just nonsensical.
[color=blue][color=green][color=darkred]
>> > . . . That is, unless you falsely imagine that the extra
>> > flexibility MS designed into Access 12 reporting will be able
>> > to handle every situation. . ..[/color]
>>
>> They are keeping the same report designer UI and adding a new
>> Layout view, which is like an editable print preview. Sounds like
>> a good thing to me -- use the old methods where they work best,
>> and the new ones where those are better.[/color]
>
> No VBA behind a report. . . .[/color]
Where is this stated? Nowhere, so far as I can see. The Access 12
blog recently had a post with extensive discussion of the new report
designer:
http://blogs.msdn.com/access/archive...13/531116.aspx
Nowhere in there does it say anything about there being no VBA code
behind the report. Of course, it doesn't relaly discuss coding,
because the focus of the post is on the end-user aspects of Access,
rather than the developer aspects.
Indeed, statements like this:
Easier to extend Access apps with Visual Studio – despite our
best efforts, Access will not offer all the power of Visual
Studio, and for some tasks developers will want to use VS. We
believe a key part of the strategy needs to be to make it easy
for VS developers to extend Access apps without having to
re-write them. Office 12 does this to some extent (e.g.
workflows written in the SharePoint Designer can be easily
edited in VS), but there is clearly more to do here.
from this post on "Access's Commitment to Developers":
http://blogs.msdn.com/access/archive...30/498466.aspx
You'd think that if what you say is true, this quotation that shows
substantial distancing between Access and VS would simply make no
sense.
[color=blue]
> . . . So much for the old methods. If you're happy
> with what Access 12 can do natively then things are better with
> the new design.[/color]
There is no evidence anywhere that Access 12 is going to remove the
old ways of doing things. Indeed, in the discussion of the new
layout view in the report designer, the point is made quite clearly
that the old design view is still going to be available because a
lot of tasks remain that will be better accomplished in that view
than in layout view.
The completely absence of any mention of the elimination of VBA
suggests to me that it's going to be there. And the repeated
insistence on backward compatibility suggests to me that you are
wholly mistaken in your assertions about about VBA and .NET in
Access 12.
[color=blue][color=green]
>> How the report definition is actually stored is really completely
>> irrelevant to me, as I don't have access to that, in any case,
>> unless I want to do a SaveAsText (which I never do, unless I'm
>> trying to recover a corrupted report).[/color]
>
> The XML for the report is already in plain text. SaveAsText won't
> help corrupted reports. You'll need to start indenting the XML
> source for that :-).[/color]
Non sequitur.
The point is that if the UI for designing and using the report, and
the coding environment remain the same, a change in the storage
format is completely irrelevant for 99.99% of Access programmers and
end users. It's only the small number of cases where you've built
something that depends on the undocumented SaveAsText that you'd run
into a problem if the storage format has changed.
I have seen nothing in the information distributed about Access 12
that says you'll be designing your reports by manipulating XML
directly. If you have information from MS that says this is so,
then, please, provide a citation of it.
[color=blue][color=green][color=darkred]
>> > . . . MS had good reasons for going in these directions so
>> > I'll try not to mourn the death of Access too long. . . .[/color]
>>
>> What in the world are you talking about?[/color]
>
> Everything needed to move toward something that would work for the
> internet/intranet world. I was talking about eliminating VBA and
> the way mdb files are stored. Those are good things in the long
> run. I just need to find something that makes up for the loss of
> VBA.[/color]
THERE IS NO LOSS OF VBA.
THERE IS NO LOSS OF THE MDB FILE FORMAT.
THERE IS NO MOVE TOWARDS DIRECTLY MANIPULATING XML FOR REPORT
DESIGN.
You are simply wrong on all counts about what is happening with the
design of Access 12.
I've seen for years many people speculating that what you describe
would happen with the post-2003 version of Access, but it isn't
happening after all. Your assertions seem to me to be derived from
all the baseless speculation from people outside Microsoft and
outside the Access development team.
My information is based on information direct from one of the leads
of the Access development team.
[color=blue][color=green][color=darkred]
>> > . . . I'll do the best I
>> > can to create a RAD environment without what we once understood
>> > Access to be. [cliche alert] Putting Access' clothes on .NET
>> > reminds me of a certain silk pigskin wallet. [cliche alert] It
>> > seems that the reports of Access' demise were not premature.[/color]
>>
>> Are you completely insane? None of the things you are talking
>> about are going to happen according to the official Access blog
>> on MSDN.
>>
>> None.[/color]
>
> I don't think it's going to be Access anymore. . . .[/color]
THe key words there appear to me to be "I think."
But you have absolutely no factual basis for making these claims.
[color=blue]
> . . . I think it's going
> to be SQL Server and .NET with some flexible XML writing thrown
> in. . . .[/color]
Well, then you're just WRONG. It's going to be the new Access db
engine (which is derived from Jet and backwardly compatible with
Jet) with VBA and no required XML manipulation.
[color=blue]
> . . . I think it's going to be more powerful than before. I think
> the development process will be slower. . . .[/color]
So far as I can see, we already have what you're describing by
simply using the existing .NET development tools. There would be no
utility whatsoever in making Access like those tools, because
Microsoft would then have two products that are nearly identical in
functionality.
Secondly, such a set of tools would not serve the end-user market at
all. It's quite clear from the posts on the Access blog that the
Access team is putting a huge amount of effort into enhancing
Access's user-friendliness for non-programmers. That move is in
direct contradition of all your assertions about the loss of RAD,
since the RAD features in Access come directly out of the end-user
ease-of-use features.
[color=blue]
> . . . Visual C++ is extremely
> powerful but I don't design databases with it. I hope you're
> correct about being able to use ADO or DAO like before without
> resorting to .NET coding. . . .[/color]
I don't know (or care) about ADO, but Jet is not going away. It is,
in fact, getting a new lease on life, with significant new
development resources going into it. Yes, it will be a different
version of Jet with different capabilities, but that's a *good*
thing, in my opinion.
Now, I'm not wholly pleased with all aspects of the direction of
Access 12. For instance, it's quite clear that Jet replication is
going to be deprecated in favor of SharePoint services. What that
means is that those who want data shared at multiple sites are going
to have to add a server to the mix, and spend extra money for server
software and infrastructure in addition to the development costs
involved, whereas with Jet replication, there was no need for
additional servers or software (though development costs are
significant).
I'm not thrilled with the SharePoint integration in general (not
just with regard to replication), since I just don't see the value.
I don't understand the concepts behind it (which the Access 12 blog
seems to me to treat as something everybody should already know
about) and I don't see any value in it for my clients. It looks like
another example of enterprise-friendly design being stovepiped onto
the small business user. Microsoft Outlook's connection to Exchange
Server is a past example of this, where the software product was
basically pretty much useless without the back end server in place
-- it promised things it couldn't deliver without introducing a very
difficult to maintain server into your network (Exchange 2003 is
much easier to administer than previous versions, but it's still a
bitch compared to not having to maintain a separate server).
Perhaps I'm wrong about this. Perhaps SharePoint services can be run
on a workstation, peer-to-peer, and perhaps they are easy to
administer. I don't know. But I still don't understand what needs
they satisfy -- I have no clients who are crying out for
collaborative document sharing. None.
So, I don't see that the effort going into making Access
SharePoint-friendly is going to help any of my clients at all. My
best hope is that it won't promise things (like shared calendars in
Outlook) that can't be delivered without the server, and that the
features necessary to support it won't make the product without it
more difficult or more confusing to use.
[color=blue]
> . . . I don't think that the new flexibility
> that reports are going to have. . .[/color]
You mean "layout view" or are you talking about your imaginary XML
editing of reports?
[color=blue]
> . . . is enough to justify calling the
> new .NET thing Access. . . .[/color]
There is no such thing as a product called "Access" with .NET
incorporated into it.
[color=blue]
> . . . Even custom SQL will have to be part of
> the .NET code. [mangled cliche alert] If it looks, sounds and
> acts like .NET then it is a dog :-).[/color]
You are completely in fantasy land. There is no support anywhere in
the materials describing Access 12 that supports any of your
assertions about what Access 12 is going to be.
None.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
