Re: Is ADO dead?

CDMAPoster@xxxxxxxxxxxxxxxx wrote in
news:1140473264.336191.248080@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
CDMAPoster@xxxxxxxxxxxxxxxx wrote in
news:1140467379.516010.154970@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
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.

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.

It's possible that ADO and DAO will be available in Access 12. . .

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.

. . . but SQL
Server Express without VBA definitely seems to be where MS is
heading. . .

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/2005/10/13/480870.aspx

I have not seen any indication anywhere that VBA will be able to
be used in Access 12 at all. . . .

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/

. . . I may be wrong. . . .

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/2005/11/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.

. . . 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.

This is all so much fantasy. It has no basis in any reality that
Microsoft has described for Access 12.

[cliche alert] It's starting to look like they dumped the RAD
baby out with the bathwater. . . .

If your major premise is wrong, your minor premise cannot be
proven.

That may be so, but VB.NET or C# is quite a bit slower to develop
in than VBA.

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.

. . . That is, unless you falsely imagine that the extra
flexibility MS designed into Access 12 reporting will be able
to handle every situation. . ..

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.

No VBA behind a report. . . .

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/2006/02/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/2005/11/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.

. . . 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.

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.

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).

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 :-).

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.

. . . MS had good reasons for going in these directions so
I'll try not to mourn the death of Access too long. . . .

What in the world are you talking about?

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.

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.

. . . 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.

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.

I don't think it's going to be Access anymore. . . .

THe key words there appear to me to be "I think."

But you have absolutely no factual basis for making these claims.

. . . I think it's going
to be SQL Server and .NET with some flexible XML writing thrown
in. . . .

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.

. . . I think it's going to be more powerful than before. I think
the development process will be slower. . . .

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.

. . . 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. . . .

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.

. . . I don't think that the new flexibility
that reports are going to have. . .

You mean "layout view" or are you talking about your imaginary XML
editing of reports?

. . . is enough to justify calling the
new .NET thing Access. . . .

There is no such thing as a product called "Access" with .NET
incorporated into it.

. . . 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 :-).

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/
.

Relevant Pages

  • Re: Is ADO dead?
    ... as SQL Server Express more than takes ... Microsoft is really eliminating Access and VBA. ... and reporting in XML. ... They are keeping the same report designer UI and adding a new Layout ...
    (comp.databases.ms-access)
  • Re: access report crash
    ... I have updated the server with no change in the problem. ... No vba call can be preformed from a report. ... I have been searching theses boards for 3 days with no help. ...
    (microsoft.public.access.reports)
  • Re: Server Performance Report - Memory in use - showing No data
    ... Please find below the report I received this morning. ... There still isn't any 'Server Specifications' or 'Memory use' data ... click the Backup snap-in in Server Management, ... Critical Errors in Application Log ...
    (microsoft.public.windows.server.sbs)
  • Re: Erroneous E-mails sent entries in Server Usage Report
    ... One of the sbs2k3Sp1 boxes did previously report outgoing messages correctly in the Usage Report. ... I gave up modifying the default recipient policy years ago and now create my own policy on each server before creating users. ... the information "E-mail sent to external recipients" lists *zero* messages being sent by all users other than Administrator. ... Please check the Message Tracking Center. ...
    (microsoft.public.windows.server.sbs)
  • Re: Server Performance Reports broken
    ... I'll try to reinstall R2 and report back on how that goes. ... we cannot remove WSUS from R2 features directly. ... tries to collect WSUS information and WSUS node still appears in Server ... Step 1: Reinstall monitoring component: ...
    (microsoft.public.windows.server.sbs)