Any consensus on stability/readiness of Access 2007 runtime?

[dbguy_atlanta]

This question is intended for MVP's, consultants, etc., who develop and
deploy Access projects in larger/multiuser environments (at least 5 users and
up)...

Is there any consensus on whether or not the Access 2007 runtime is really
ready for production use in "serious" (at least 5 users, many forms, many
reports, complex forms, etc.) projects?

I'm a long time user of previous versions of Access for these kinds of
projects and bitter experience has taught me to be extremely weary of
Microsoft's new product releases. Also, I see plenty of chatter on the
internet concerning all sorts of problems with 2007 but as is always the case
it's hard to know the person's level of experience and knowledge of the
product.

On the otherhand, all versions of Access have been left with many unresolved
bugs; there's another view that I might just as well plunge in and plan to
work around whatever quality problems exist in 2007 as I have done in all
past versions. Trying to wait for a 'clean' version of 2007 might well be
hopeless.

I'd also be curious to get feedback on what others consider to be the most
reliable/stable version of access in a large production environment (I'd
probably pick Access 2002).

Thanks in advance.

 

[Stefan Hoffmann]

hi,

dbguy_atlanta wrotw:

Is there any consensus on whether or not the Access 2007 runtime is really
ready for production use in "serious" (at least 5 users, many forms, many
reports, complex forms, etc.) projects?

Consensus? Ever met a bunch of MVP's or consultants ?)

From my point of view:
It's as stable as the previous runtime versions. It won't run smoothly
on all systems for all type of possible applications... but it does is
job. I would say, almost as intendend.)


mfG
--> stefan <--

 

[dbguy_atlanta]

Consensus? Ever met a bunch of MVP's or consultants ?)

Good point. I think I regret the wording of the question already. I probably
should have asked how many MVP's, consultants, corporate developers, etc.,
are using the 2007 runtime successfully for large (5 users + and
many/complicated forms/reports) Access projects and left it at that.

No responses would be suggestive.

 

[a a r o n _ k e m p f]

I've used previous versions of the runtime with quite a bit of
success.
I never had any need to buy SageKey or any of that junk.

I think that the real problem, is that people don't understand how to
work with multiple versions of MS Access on your machine.
I reccomend adding shortcuts to each version of MS Access (on the
machine) to the sendto directory, so that it is easier for your end
users to open Access1 with either Access 2003 or 2007, depending on
what they're trying to do.

I think that having multiple versions on a machine is not always a
requirement.
But when it is necessary you need to set it up for your end users.

I think that this is one of the biggest hassles.

If you can upgrade everyone to only using Access 2007- that's great.
I just find that there's always one user that doesn't want to give up
X.

In that case, it might be best to get them a full version of MS
Access.

 

[a a r o n _ k e m p f]

and more importantly, you should contact MS about any bugs you find.

they need to get 10,000 Acceess developers complaining about X,Y and Z
so that we can start doing a better job- as a community- instead of
having some MVPs launching personal crusades (because they have short
mans complex).

 

[GenlAccess]

I think that . . .

I think that . . .

I think that . . .

The Command Panel of Experienced Access Users have advised that they
seriously doubt the quoted text.

On the basis of careful analysis of a multitude of your postings, they
determined that either you are unable, or that you are too lazy to, actually
"think".

The analysis report indicates that a possibility, although it seems remote,
would be that you have no idea what it means to "think".

Gen'l Access

 

[Allen Browne]

dbguy, run a test install and see how you go. I think you will be pleasantly
surprised at how straight-forward the process is. It doesn't have the power
of some of the commercial installation packages, but it's a simple and
fairly trouble-free operation.

As far as stability goes, you are probably aware that the runtime actually
uses the same msaccess.exe as the full Office installation, so the stability
is the same. That means you need to be aware of the same issues as you do
when developing for clients who have Access 2007. Provided that SP1 is
installed, that's quite usable IMHO. (Since you say you have experience with
the A2002 runtime, I'm assuming you already know how to develop for
runtime - full error handling and so on.)

I'm sellling A2007 runtime packages now, and not getting any more support
issues than previous versions. (Previously A2002 runtime was my choice.)

HTH

 

[dbguy_atlanta]

Thanks for your response Allen. What are you finding with 2007 in situations
where say 5 to 25 (or more?) users are involved in concurrent access, either
to a shared back-end MDB, an ADP/SQL Server connection, an ODBC/SQL Server
connection, or ODBC/MySQL connection????

I have done limited testing with the 2007 runtime so far, one user in a
group of about 10 users (everyone else is running 2002) accessing a shared
MDB back-end via separate front-ends. So far the lone 2007 user seems to be
doing ok and does not appear to be affecting the 2002 users. I've just been
burned too many times in the past when a new version looked ok at the start
but deeper in (and too late to turn back) I found some really nasty bugs or
discovered that Microsoft had made some (what I call) "let them eat cake"
omissions or changes that really screwed me up.

By the way, I thought the runtime required it's own service pack for updates
regardless of whatever shared components the runtime and full version may
have in common?

Thanks again for the response.

 

[Allen Browne]

I can only comment on the MDB back end. Works fine. I'm not seeing new
issues with mixed version (A2000 - 2007) users sharing the same MDB. (They
each have their own front end, of course.)

The runtime with SP1 included is:
http://www.microsoft.com/downloads/...D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en

Info on chaining other things into the install:
http://msdn.microsoft.com/en-us/library/bb687991.aspx

 

[david]

By the way, I thought the runtime required it's own service pack for

updates
regardless of whatever shared components the runtime and full version may

I haven't seen any runtime (or viewer) patches, so either they aren't
updating it, or it just uses the standard office updates. Probably the
later.

The problem would be if you unbundle all the pieces, and included
them in your own installer. That would break updates: you have let
your installer run the runtime installer, not take the individual files off
an installed system.

There are sometimes problems when you patch a runtime/viewer/
edition, then later install the full version. That used to be a problem,
but it has mostly been fixed, sometimes by requiring a complete
uninstall before a re-install. Except for @!xx$% "XML services 4.0"
That set of patches is still broken if you don't install, patch, and
upgrade in the correct order.

(david)

 

[a a r o n _ k e m p f]

I'm a certified DBA, SQL 2005.

Are you?

I'm a free thinker on this group. I question GROUPTHINK.

Maybe you should take a class on a real-mans database, kid!

-Aaron

 

[dbguy_atlanta]

Allen, you're not seeing any significant slowdown using 2007? That's very
surprising to me. I've got systems developed in 2003 with some fairly complex
windows (8 or 9 tabs, several sub forms, various lookups and combo boxes,
etc.) that work great with 2003 (instant responses, very rapid display of
records when moving from record to record, etc) but which run much more
slowly under 2007.

You have not observed any significant drop in performance moving to 2007????

 

[Allen Browne]

Can't say I've run any real timing tests, using the same data on the same
hardware under different versions.

But neither am I getting complaints from users with the new version runtime.
Perhaps I've configured the systems to avoid known issues, or avoided the
particular bottlenecks you are talking about, or ...

 

[dbguy_atlanta]

Thanks for the info. Maybe my recent test was a fluke, I'll have to try
running another 2002 or 2003 system with 2007 and see what happens. In my
case I didn't need a stop watch, the difference in performance (running on
the same PC) was extremely noticeable.

If I could ask one other thing: what is the largest number of simultaneous
users you have experience with (shared MDB backend, ADP or ODBC connection)
using 2007??? I do mostly multiuser systems, that aspect is very important to
me.

 

[Tony Toews [MVP]]

Allen, you're not seeing any significant slowdown using 2007? That's very
surprising to me. I've got systems developed in 2003 with some fairly complex
windows (8 or 9 tabs, several sub forms, various lookups and combo boxes,
etc.) that work great with 2003 (instant responses, very rapid display of
records when moving from record to record, etc) but which run much more
slowly under 2007.

I've read the occasional posting in the newsgroups but that's about
it.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Allen Browne]

Probably half a dozen users. (Have only been installing the A2007 runtime
for a few months.)

 

[David W. Fenton]

I've read the occasional posting in the newsgroups but that's
about it.

It might be worth preparing the MDB for distribution in Access 2007
by recreating (not relinking) your table links in A2K7 and
decompiling then recompiling in A2K7 itself. And, of course, if
you're distributing an MDE with the A2K7 runtime, create it in A2K7,
not earlier versions of Access.

 

[dbguy_atlanta]

Thanks David, I did not think about recreating the links in A2K7 instead of
relinking. Sometimes this kind of "voodoo troubleshooting" (my term for any
troubleshooting approach that really should not make a difference) does the
trick.

Question on decompiling: I thought this was a thorny issue, that sometimes
decompiling causes problems and Microsoft has suggested rebuilding MDB's
rather than trying to decompile? Let me admit ignorance on this topic, of
course I've been compiling MDB's and creating MDE's for a long, long time but
for one reason or another I've never looked into decompiling, the benefits,
risks, etc.

 

[Allen Browne]

David will probably reply as well, but decompiling moved from and
undocumented (voodoo?) tip in early versions to something that has been
documented and supported for several versions.

My personal practice is to decompile every time I switch versions, and
whenever the VBA code starts misbehaving.

You probably understand the concept: a database contains both the text
version of the (what you view and edit), and the binary version (the
'compiled' stuff that actually runs), and these 2 things can get out of
sync. Every version uses a different binary, so when you switch version
(even between original A2007 and A2007SP1), Access silently recompiles the
new binary.

This doesn't work perfectly, and so you get weird stuff discarded binary
that's still present, breakpoints that don't break, or even deleted code
that still executes. Decompiling instructs Access to dump the binary. It
then re-creates it from the text version, so the inconsistences are gone and
what executes matches what you see.

The sequence that works for me is:
1. Make a copy of the MDB (in case something goes wrong.)

2. Compact (dumps any deleted stuff)

3. Decompile (dumps the binary), holding down Shift so any start-up code
does not execute.

4. Compact again (actually removes the dumped binary), still holding down
Shift.

5. Compact again (because a compact after a decompile doesn't work in some
versions, unless you restart in between.)

6. Compile (verifies the text version is fine.)

7. Possibly another compact, and then back up.

 

[Allen Browne]

Today's example of "... the VBA code starts misbehaving."

MDB created in A2003, but recently opened in A2007. Now when I open it in
A2003, the startup form throws error 2455:
You entered an expression that has an invalid reference
to the property BeforeCommitTransaction.

That's fairly senseless, as BeforeCommitTransaction is not user-settable,
has never been tampered with, and in any case would not apply to an unbound
form.

Decompiling solved the issue.