Are there known issues with Vista and Acc2003

[Rick Brandt]

That's a valid point against ADO if you are only interested in
performance. Now think about data integrity: some database constraints
(including primary keys) cannot be implemented with indexes and
Validation Rules alone (big hint: table-level CHECK constraints). But
that that's just two issues out of many so let's not do the ADO vs DAO
thing again here and instead focus on the question in hand i.e. should
one avoid a feature (ADP) merely because 'Micosoft support' no longer
recommends it?

Merely? How about the tons of things that suck about them? Most Access
developers saw the folly of ADPs even when MS was encouraging their use. To say
that they are not recommending them now "merely" because MS has stopped pushing
them is a bit of a stretch.

The attitude change from MS is simply a bit of validation to the arguments that
have been there all along.

 

[Lyle Fairfield]

I don't think that's correct. JRO is an ADO component (seehttp://msdn2.microsoft.com/en-us/library/aa189021.aspx) and David
knows more about JRO than most, including me and I'm an ADO advocate.

So David is an ADO user and advocate? Wonderful! I'm so pleased.

But I'm puzzled why one week ago he posted:

"I wouldn't use ADO at all. Ever."

 

[Baz]

This is completely untrue.

Yep, right, whatever.

 

[Baz]

"ADO 6.0 is included in Windows Vista, as a part of the Windows Data
Access Components (Windows DAC) 6.0. ADO 6.0 is functionally
equivalent to ADO 2.8."

Jamie.

I'm sure Vista contains lots of stuff for backward compatibility that MS has
no intention of further developing.

 

[Baz]

Doesn't the existence of ADO 6.0 for (as you say) backward
compatibility prove MSFT's commitment to fixing ADO "problems under
Vista"? Otherwise, they would have just shipped MDAC 2.8, surely?

Jamie.

Not at all. According to that quote of which you were so proud, this ADO
6.0 is "functionally identical" to the previous version, which suggests to
me that it's only purpose is to provide backward compatibility. Presumably
there were technical reasons why the previous version wouldn't work under
Vista (or, it is in fact exactly the same thing and they just renamed it).

I fail to understand why you are so keen to prove that ADO has a future.
You like it? Fine, it's still there, carry on using it. But, it's
blindingly obvious to me that Microsoft lost interest in it years ago, just
as it did ADP's, and probably regrets inventing both technologies and hence
adding to it's backward-compatibility headaches.

 

[Lyle Fairfield]

Take another look at what I wrote.

I have. It seems that what I read was not what you wrote. Thank you
for clarifying.

 

[David W. Fenton]

Oops, missed this earlier!

That's a valid point against ADO if you are only interested in
performance. Now think about data integrity: some database
constraints (including primary keys) cannot be implemented with
indexes and Validation Rules alone (big hint: table-level CHECK
constraints). But that that's just two issues out of many so let's
not do the ADO vs DAO thing again here and instead focus on the
question in hand i.e. should one avoid a feature (ADP) merely
because 'Micosoft support' no longer recommends it?

The Jet db engine doesn't support the features you are talking
about. And they aren't really relevant to a data interface language
like ADO, anyway. Setting them up and modifying them is a matter of
DDL for the relevant database engine, and I doubt that Jet or ADO
mucks around with DDL statements before handing them off to a
server.

Microsoft purposely muddied the waters by intentionally not updating
DAO 3.6 to support new features in Jet 4, and added support for a
handful of Jet features only in ADO. I hope that with A2K7 and a new
commitment to DAO and Jet, that MS has done the right thing and
implemented direct support for all of the features of the db engine.

 

[Tony Ciconte]

Tony,

Thanks for the question and, to answer some of the other responders,
this is a commercial product that has been sold all over the country
since 1996. Most of that time we have used the Wise Installer with
SageKey scripts to place a solid runtime environment on the user's PC.
I am hopeful that the good folks at Sagekey will update their products
to handle Vista in the near future but until then my specific issues
are:

1) Performance is quite slow on a new Dell PC with 2GB, dual core
processor, Vista Ultimate and running an Acc2003 MDB under Acc2007.
2) The tabbed form doesn not always close and seems to refresh and
flash when closing on other occasions.
3) Screen resizing code (modResizeForm), fully attributed to Jamie
Czernik, does not always run properly. I suspect I can probably get an
update for this code if necessary.
4) Of course, the new ribbon plays havoc with the user interface and
placement of our custom tool and menu bars but we will have to live
with it unless somebody knows a way to change that behavior.

One other question...has anyone successfully implemented a runtime of
any previous evrsion of Access on a Vista PC with and/or without
Acc2007 installed?

Thanks again for any and all responses.

TC

 

[Larry Linson]

Doesn't the existence of ADO 6.0 for (as you say) backward
compatibility prove MSFT's commitment to fixing ADO
"problems under Vista"? Otherwise, they would have just
shipped MDAC 2.8, surely?

"Classic ADO", which is what you are discussing here, has been superceded in
the Microsoft world by ADO.NET, which is a different product entirely,
sharing only part of the name, and not based on OLEdb, as is classic ADO.
Whether it was a workable and usable technology (it was, though in my
personal opinion, no _better_ than DAO, even if each had unique features not
supported by the other) is not really material.

And, FYI, though my use of ADP/ADO has been less-than-extensive, I did not
encounter anything I needed to use that "just didn't work", but the fact
that Lyle thinks so well of it is a convincing argument for me that it had
potential that was "cut off in its prime" by corporate technical direction.
Lyle and I have had occasion to "cross words" (much less traumatic than
"crossing swords", BTW), but I have a high respect for his technical
judgement.

Out of consideration for those who adopted classic ADO and used it,
Microsoft has kept it around* and, presumably, if defects are found, they
will consider the business case for fixing them (always a trade-off, in the
corporate world -- a defect, no matter how long-standing, that affects only
a few users will be near the bottom of the priority list for investigation
and correction). But, it is not a technology in which Microsoft can be
expected to make investments "going forward".

* Access' Data Access Pages (DAP), on the other hand, were
so little adopted and used, that while existing DAPs are
supported, Access 2007 does not support creating new ones
nor maintaining the old ones. You can still create a new
Access Project (ADP), still maintain existing ones, and ADO
can still be used (I am not, however, certain about Classic
ADO and the new ACCDB database format), so it has not
officially been "deprecated". It's just not something you want
to bet your future on.

Larry Linson
Microsoft Access MVP

 

[Lyle Fairfield]

ADO
can still be used (I am not, however, certain about Classic
ADO and the new ACCDB database format),

I posted about this some months ago. There is a new ACE provider and
ADO works just fine with Access 2007 and its various associated
technologies.

so it has not
officially been "deprecated". It's just not something you want
to bet your future on.

I think that if that's the case then you and the other MVPs who
believe as you do should encourage Micorsoft to take down this page
where it says:

ADO will continue to be ENHANCED
Jet is DEPRECATED
and
DAO is OBSOLETE,

http://msdn2.microsoft.com/en-us/library/ms810810.aspx

entitled Data Access Technologies Road Map

because here's what Micorsoft says about ADO:

"ADO: ActiveX Data Objects (ADO) provides a high-level programming
model that will continue to be enhanced. Although a little less
performant than coding to OLE DB or ODBC directly, ADO is
straightforward to learn and use, and can be used from script
languages such as Microsoft Visual Basic® Scripting Edition (VBScript)
or Microsoft JScript®."

and here's what it says about JET:

"Deprecated MDAC Components
These components are still supported in the current release of MDAC,
but might be removed in future releases. Microsoft recommends that
when you develop new applications, you avoid using these components.
Additionally, when you upgrade or modify existing applications, remove
any dependency on these components.

Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
or the ODBC Desktop Database Drivers."

and here's what it says about DAO:

"Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from
future product releases. Do not use these technologies when you write
new applications. When you modify existing applications that are
written using these technologies, consider migrating those
applications to ADO.NET.

The following components are considered obsolete:

Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic®,
Microsoft Visual C++®, and scripting languages. It was included with
Microsoft Office 2000 and Office XP. DAO 3.6 is the final version of
this technology. It will not be available on the 64-bit Windows
operating system."

I've posted these line several times before. I didn't make them up.
They are in a Microsoft article whose introduction is:

"This article describes the past, present, and future of Microsoft
data access technologies, including DB-Library, ESQL, DAO, Microsoft®
Data Access Components (MDAC) (including ODBC, ADO, and OLE DB),
ADO.NET, and SQL Native Client. This article identifies which
technologies are being enhanced, and which technologies and components
are being deprecated or excluded from future releases."

I think that MVPs should use their influence to have Microsoft tell us
the real story as revealed to the MVPs and their supporters, or the
MVPs should stop saying ADO is dead, because there are beginners here
who think that MVPs know what they are talking about. And in this case
it's clear; they don't, or Microsoft isn't fessing up.

 

[CDMAPoster]

It's not DAO or ADO that is deficient or dying. They're both great in
Microsoft land. But the rain isn't falling on Microsoft land much any
more. And the soil is drying up. And there are skeletons on the
plains. No one is noticing. But someday soon we will look at the old
vista we remember, and it won't be the same.

Was that a pun on vista ?

While it's true that the demographics of rich-yet-technologically-
naive companies on which Microsoft has depended is on the decline,
there are signs that Microsoft is changing for the better. A lot of
the impetus for Microsoft gaining so much market share was relying on
the fact that 99% of the time, large companies take the easiest way
out. It's very impressive how Microsoft went about leveraging the
advantages they had. As companies get more technologically savvy
they're not willing to pay the highest costs associated with ignorance
and the "easy" way. I think Microsoft sees that gradual change in the
market and are fighting to hang on to potentially fleeing customers.
It's just too bad that Microsoft had to adopt this attitude under
coercion, kicking and screaming, because I believe they've always had
the talent available to create exceptionally fine products. Microsoft
is learning that the current product buggy life-cycle path is rapidly
becoming inadequate. I think they'll be able to take steps to replace
the old paradigms. IMO, their having a prioritization plan in place
for fixing bugs in current products based on a set of metrics (future
revenue? ) is one of those steps. That shows that their focus is
on the bottom line -- where it should be. Of course, had they taken
these steps earlier they would have missed out on some extra revenue
due to the number of customers willing to "ride" that particular
treadmill. Microsoft is not stupid and will adapt their ways to ways
that make the most money for a given software environment.

Even UNIX land is no panacea. UNIX implementations, until Microsoft
showed how to make things easier for the user, were a nightmare to use
compared to the ease of things today. Without Microsoft being there
to help redefine OS priorities and reshape user expectations UNIX
usability would not be where it is today. So much for
conscientiousness. UNIX still has a way to go in providing
convenience for users and developers. Although some might say
that .NET is Microsoft's attempt at pushing their bugs beyond the
local machine, it has the capacity to bring convenience to an
inconvenient web world.

Open source is garnering the best ideas from Microsoft, Microsoft is
trying to implement the best ideas from open source, and I'm trying to
get the best from both .

Oh, the topic! I never dismiss DAO or ADO before looking at a
project's current and projected requirements. Er..., the topic! I
have not used Vista yet but I plan to buy a machine (I know it won't
run well on old machines) soon to run it (not a home version of Vista)
at home. Until I start discovering my own set of issues I will be
acutely interested in the experiences of others. I note that the
plethora of Vista versions will make it harder to generalize about how
various Access versions will run under Vista. I.e., I suspect that
there will be a dilution of OS specific experience.

James A. Fortune
(e-mail address removed)

 

[Michael]

It may not be related to Vista. I work with another product developed
in Access with about 15K lines of VBA code -- using DAO. After I
installed Office 2007 on a Windows XP machine (no previous version of
Office has been installed on it), I have found this product to be
nearly unusable in Access 2007 because of slow performance in forms.
The same product works fine in Access 97, 2000, XP, and 2003. I get
the same results whether I keep the 2002-2003 file format or convert
it to the 2007 format. Thus far, no Access MVP has been able to offer
any insight on what might be the problem.

 

[Larry Linson]

I posted about this some months ago. There is a new
ACE provider and ADO works just fine with Access
2007 and its various associated technologies.

Thanks for the reminder, Lyle. I'd forgotten about your post on the subject

I think that if that's the case then you and the other MVPs
who believe as you do should encourage Micorsoft to
take down this page where it says:

ADO will continue to be ENHANCED
Jet is DEPRECATED and
DAO is OBSOLETE,

http://msdn2.microsoft.com/en-us/library/ms810810.aspx

Good suggestion, Lyle. I believe you'll find some conflicting information,
perhaps in the Access 2007 blogs -- it's a massively vast website, and I'm
not surprised that not all pages are up-to-date. The one you cite here
shows a most-recent-date-of-update of December 2004. I will forward the
suggestion, with my "endorsement" that it is a good idea to make the website
consistent and consistent with current recommendations, to a contact at
Microsoft.

HOWEVER, bear in mind that "If you are looking for someone with a little
influence at Microsoft, you've come to the right person, because I have as
little as anyone."

Larry Linson
Microsoft Access MVP

 

[Rick Brandt]

That's a valid point against ADO if you are only interested in
performance. Now think about data integrity: some database constraints
(including primary keys) cannot be implemented with indexes and
Validation Rules alone (big hint: table-level CHECK constraints). But
that that's just two issues out of many so let's not do the ADO vs DAO
thing again here and instead focus on the question in hand i.e. should
one avoid a feature (ADP) merely because 'Micosoft support' no longer
recommends it?

Merely? How about the tons of things that suck about them? Most Access
developers saw the folly of ADPs even when MS was encouraging their use. To say
that they are not recommending them now "merely" because MS has stopped pushing
them is a bit of a stretch.

The attitude change from MS is simply a bit of validation to the arguments that
have been there all along.

 

[Larry Linson]

From the 'outside' it's hard to see how things will
play out e.g. DAO has made a comeback seemingly
against MSFT's game plan so will ADP survive in
coming years with enough support to make it viable?

My observations elsewhere for many years, and of Microsoft in recent years,
make me certain that predicting anything more than one version ahead is just
a wild guess (and, that is sometimes true even for 'the next version'). For
example, I sincerely doubt that, two versions back, anyone outside
Microsoft, including FrontPage MVPs, would have predicted FrontPage would be
gone by now (although it has two "offspring" that will carry on the
tradition -- SharePoint Designer and Web Expressions) but there is not, and
will not be, a FrontPage 2007.

My impression is that Microsoft's emphasis for Access, now, is as an
end-user tool for the Information Worker and that ADP was a "developer"
emphasis, so I would be concerned -- but that's not based on anything but
the aforementioned "wild guesses". In the MDB world, I note that the Control
Wizards no longer generate VBA in Access 2007, but generate (the improved?)
macros, instead, and that, I take as some confirmation of my view of their
revised emphasis.

I do, indeed, believe that classic ADO has been superceded in the Microsoft
development world. The "poor old fellow" has been taken in to the Access
assisted-living facility and is being nursed along with occasional doses of
Software Growth Hormone (e.g., the support for ACCDB); the "young and
vigorous" ADO.NET is thriving in the Microsoft "world of development" which
is, patently obvious to the casual observer, DotNet-centric, not
Office-centric.

Larry Linson
Microsoft Access MVP
(and Independent Prognosticator with Extremely Cloudy Crystal Ball)

 

[David W. Fenton]

David has used ADO not at all, or very little.

I tried it out. I've worked with ADO code in existing apps. I've
read tons of documentation with ADO code (and it's ugly
stepchildren, like JRO). I've been doing all of these things since
1999.

He has not studied it.

I studied it extensively in the early days, when I first got the ADH
for Access 2000. Given my client base, it was of no use to me. Had I
apps with SQL Server back ends, I would likely have used ADO for
certain operations in that context.

He has neither the skills nor the experience to implement it, yet
he constantly denigrates it and expresses absolute opinions about
it.

You don't have to be an architect to tell that a house is falling
down.

David is not alone. He is joined by MVPs and other experienced
Access developers. I often wonder why. Is it because they are
inherently conservative and do not trust this new (what 1998?)
technology?

It was obvious that the ADO-everywhere push by Microsoft with the
release of A2K was a mistake for Jet projects. It was obvious to me
that the whole basis of ADPs (i.e., a Jet-less front end to server
data) was based on an unjust prejudice against Jet, caused by
ignorance and misunderstanding of Jet by developers who never
bothered to learn how to use it properly.

The problems with ADPs emerged quickly. Developers like Steve
Jorgensen tried very hard to make ADPs work and he was no slouch in
the programming department -- a very smart guy. If he couldn't make
it work, then nobody could. And he gave up on ADPs completely after
the second version fixed some bugs while adding new ones.

Is it
because they have a cozy business based upon Access and DAO?

I never criticized ADO in a non-Jet context. Ever. I only criticized
the ADO-with-Jet approache, which was always completely nonsensical.
I also criticized (as above) the philosophical foundation for the
introduction of the ADP (i.e., "avoid Jet at all costs"). As it
turns out, Microsoft has now adopted the very same position I was
advocating back in 1999-2000 with regard to ADO and ADPs.

Is it
because they do not have the intellectual capacity to keep several
technologies active in their brains at the same time? I don't
know.

I used the technologies that were appropriate for my clients, none
of whom use SQL Server. I learned to work with SQL Server because I
saw the need for upsizing with some of my clients. But here almost 8
years later, none of my clients have upsized (even though I've
suggested that it would be a good idea to consider it very
seriously) because Jet has worked so well with the apps I've written
for them that they just can't justify the conversion and admin
expenses.

It didn't take a genius to understand that the recommendation by MS
to use ADO with Jet data was a mistake. It didn't take a polymath to
see that the basic idea behind ADPs was problematic.

I
don't care. I can and have used DAO and ADO extensively. I have
forgotten more about DAO than many of its champions know; I have
used ADO more extensively than most. Each is a fine technology.

And I've never said ADO was a bad technology *in the proper
context*. Jet is *not* the proper context for it.

I like ADO;
it has a broad list of capabilities and it has a broad list of
situations in which it can be used.

As a successor to ODBC it's quite good.

The notion that it is dead is
absurd.

It is dead, Lyle. MS has moved on to ADO.NET and ADO is not being
developed any more.

DAO *was* dead in 1999, but it's alive again with the release of
A2K7 because MS wised up. It's not going to be "classic DAO,"
though, but a new version that will likely be updated for
compatibility with the new data format.

But when it's advantageous to use DAO, I use DAO.

But Lyle, that's precisely the argument I made for DAO from the very
beginning. I have always said that DAO was appropriate for Jet data,
though ADO was useful with Jet for a handful of features that DAO
didn't offer.

That has been my position from the beginning.

I *never* criticized the use of ADO in ADPs or with SQL Server data.

But once MS moved on to ADO.NET, classic ADO was clearly a legacy
technology, and the whole "learn it because it's the future"
justification for utilizing it in Jet-based apps went away entirely
(it was always a very weak argument).

What I do
care about and think that this newsgroup avoids is not the future
of ADO, nor of DAO. It is the future of Microsoft. Ten years ago
Microsoft did everything better; it was vibrant and it was
developing technologies which were needed and wanted. Today it is
developing redundant technologies to hawk.

I would agree with this. Office 97 was an amazing platform. But with
A2K, MS abandoned many of the promises of A97 because it wanted to
extend itself into the Enterprise market. And the design of A2K was
driven by that agenda, instead of what was best for the existing
base of Access developers and users.

Michael Kaplan published that article showing how the emperor had no
clothes and he took lots of heat from MS for it. But history has
borne out his judgments pretty darned well.

And that was the point at which I lost faith in Microsoft, because
it was clear that their priorities no longer matched those of my
client base.

I have learned all about .Net except
for one tiny thing: where I would want to use it.

I think it's obvious where .NET is a good platform -- for complex
browser-based apps. The whole CLR is a bust, though, in my opinion.
I don't see people using it to write cross-platform apps at all.

Oh I know, it's
Superior! And it may be for some. But I have not found that it is
superior for an experienced programmer/developer. And no, I don't
like apps which can do in ten thousand lines what I used to do in
eight (no, not eight thousand lines, eight lines).

On this issue you sound very much like I did in 1999 in regard to
A2K.

That amuses me a great deal.

The computer on which I am writing has Windows and its associated
technologies such as Internet Explorer installed. But it is fully
provisioned with other [FREE] software that is not Microsoft. How
much am I missing Microsoft? Not at all? What have I been unable
to do that I could do with Microsoft ? Not a thing. How many
crashes/ failures have I had with this new software during
February? None. How often and big are the updates? I don't know
because invariably the updates are so simple and swift that I
forget that they happened. I re-installed Windows XP from the
original OEM cds last week and was hit by a total of 113 updates.
One hundred and thirteen! Next I turned on a new Vista computer.
Ah, I thought, they'll be sure to have this very annoying updating
cured. WRONG! Seven updates were required. After three weeks there
were SEVEN F___KING updates required. SEVEN F___KING updates
required after three weeks of availability.

I see that as a *good* thing. MS is releasing patches for
vulnerabilities when they are found, unlike the days when MS would
ignore security issues for months and years. Criticizing MS for
these updates is really counterproductive, in my opinion. MS should
be praised for them.

(Sorry, it seems I have repeated myself) Is this
Microsoft company a JOKE or what?
It's not DAO or ADO that is deficient or dying. They're both great
in Microsoft land. But the rain isn't falling on Microsoft land
much any more. And the soil is drying up. And there are skeletons
on the plains. No one is noticing. But someday soon we will look
at the old vista we remember, and it won't be the same.

I think MS is going to be around at least until I retire. That's at
least 20 years in the future. It won't be the same MS as it is
today, but I'd bet it still has significant market share.

 

[David W. Fenton]

In the MDB world, I note that the Control
Wizards no longer generate VBA in Access 2007, but generate (the
improved?) macros, instead, and that, I take as some confirmation
of my view of their revised emphasis.

But there was actually a reasonable justification for this: macros
can be executed safely (because of the limited set of available
commands) and VBA code can't.

I still think "fear of VBA in Access" is completely overblown, and
the solution is terrible, but that's the world we live in, where MS
often provides Draconian fixes to problems that don't really exist
to the extent suggested by the seriousness of the fixes.

 

[Larry Linson]

But there was actually a reasonable justification for
this: macros can be executed safely (because of the
limited set of available commands) and VBA code can't.

Help me understand, David, why the VBA code _that is generated by the
wizards_ "can't be executed safely". They haven't done away with VBA, they
have just done away with the Wizards generating it -- you can create your
own event procedures using VBA, but, if you are a developer and going to
extend an event procedure, you are going to have to rewrite what they did
with the *&$% macros.

Do I think they have an agenda to eliminate VBA? Yes, indeed I do, unless
they have a groundswell of support from _enterprise customers_. VSTO is
already there to encourage Word and Excel developers to move to the
"wonderful world of DotNet." No amount of bitchin' from "the great Access
unwashed" is likely to have any effect.

Frankly, I've been a developer since before Bill Gates was in Junior High
School, when he was borrowing time on somebody's minicomputer to learn
programming, and much before he founded Microsoft. For me, it's a little
late to have an interest in switching to "user software support" -- that's
for the interns that the company hires from local colleges to support
technical education and scope out promising young new hires.

Larry

 

[lyle fairfield]

Frankly, I've been a developer since before Bill Gates was in Junior
High School, when he was borrowing time on somebody's minicomputer to
learn programming, and much before he founded Microsoft. For me, it's
a little late to have an interest in switching to "user software
support" -- that's for the interns that the company hires from local
colleges to support technical education and scope out promising young
new hires.

C'mon Larry. I think you'd be a natural for call-in support. You already
speak a dialect that almost no one can understand (Texan), don't you?
That's a requirement, I believe.

 

[Larry Linson]

C'mon Larry. I think you'd be a natural for call-in
support. You already speak a dialect that almost
no one can understand (Texan), don't you?
That's a requirement, I believe.

Doan chall drawl, tew?

Larry