Microsoft Access 2010 Runtime -- any better than 2007 Runtime for MDBs ?

I unsuccessfully attempted to convert 100 MS Access 2003 format MDBs to run under the AC2007 Runtime.  It was WROUGHT with problems, and ultimately, the customer decided it was no longer worth the development time I was spending, in order to save the money vs purchasing MS Office Professional for each of 50+ users.

Does anyone know if the AC2010 Runtime is truly "ready for prime time" now? And will it still run the older MDBs ?

Thanks,
Bill C.
bcreenAsked:
Who is Participating?
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Connect With a Mentor Infotrakker SoftwareCommented:
You went through 100+ databases, and  and added error trapping to all of them in roughly 23 minutes? All I can say is .... man, you're fast. I don't think I could even OPEN 100+ databases in 23 minutes.

"RTE": Are you referring to a RunTime Error? If so, can you provide details of some of those errors?

What error logging routine did you use? Failing to effectively trap errors is one of the more common causes of runtime errors.

The runtime was never intended to be a replacement for the full retail version of Access (and most professional developers hardly feel that modifying the registry to build Trusted Locations is a "hack"). The runtimes have always been nothing more than the full version of Access with Design features disabled. This can cause some angst among people who are accustomed to drag-n-drop programming, but in most cases you can easily learn the techniques to manage this.

One thing you might do is to build new, blank databases in Access 2007 (using the .mdb format) and import the older .mdb files to those new containers. This often serves to clear up any issues with those databases in the 2007 environment.

I'd also advise you to do this in those databases:

1) Compact the database
2) Compile the database - open the VBA Editor and click debug - compile. Fix any errors, and continue doing this until the menutiem is disabled
3) Compact again
4) Now import into a new database
5) Resolve any reference errors, if they exist
6) Compact the new database

Again, this is not generally a simple or quick process, and requires some time on your part. With 100+ databases, I'm sure you'll spend a few days working with this - however, I'd encourage you to pick one database (one that's giving you troubles in 2007) and work with that one until you get is right. Once you do that, you can apply the techniques to all your other database.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
The runtimes specifically state that they are intended to run "native" formats:

"The Microsoft Access 2010 Runtime enables you to distribute Access 2010 applications to users who do not have the full version of Access 2010 installed on their computers."

From here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=57a350cd-5250-4df6-bfd1-6ced700a6715&displaylang=en

Note the term "Access 2010 applications" - the ONLY apps that are certified to be compatible with 2010 runtime would be 2010 apps. To claim that the 2007/2010 runtime are "not ready for prime time" because they won't run legacy apps isn't really valid.

In most cases, the 2010 runtime will run a well-developed application that uses only native controls and such. If you use 3rd party Activex controls (even Microsoft controls, like the Calendar control) then all bets are off in the Runtime environment. Also, running your .mdb file in the runtime encompasses quite a bit more than simply opening it in the Runtime. There are quite a few steps to take when insuring that your app is ready for the runtime. In most cases, if you follow those steps, then the 2007/2010 runtime will run your .mdb files.
0
 
bcreenAuthor Commented:
Thanks for your input!  you stated: "...Also, running your .mdb file in the runtime encompasses quite a bit more than simply opening it in the Runtime. There are quite a few steps to take when insuring that your app is ready for the runtime. In most cases, if you follow those steps, then the 2007/2010 runtime will run your .mdb files..."

What are the "steps" involved?  I assume that simply "converting" the 2002-2003 format MDBs to the AC2010 ACDB format would just be a starting point, right?

0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Yes, you're correct. Here's a few document that explain most of the steps, and some issues you may need to handle:

http://msdn.microsoft.com/en-us/library/cc136539(v=office.12).aspx - Basics for Building Runtime-based deployments

http://msdn.microsoft.com/en-us/library/bb501030(v=office.12).aspx - Package & Distribute

http://msdn.microsoft.com/en-us/library/bb421308(v=office.12).aspx - Security Considerations

0
 
bcreenAuthor Commented:
I did everything in these documents that was recommended (the ones pointed to are for AC2007 runtime), EXCEPT converting to ACCDBs -- this was because many users will continue to run AC2003, until we could transition them to AC2007 runtime.  And I could never get the AC2007 runtime to fully function with a  group of test users [ a catch-22 situation].

I even went to the trouble and expense of placing a highly rated error trapping / logging product -- and code -- into EACH of the 100+ MDBs.  But I continued to get unexplainable RTEs with the Runtime version, that the full versions of either AC2003 or AC2007 did NOT trap at all.

Since the MDBs are all in a central location on a network, and run against a SQL-Server database, I didn't think using the packaging and distribution recommendations was really an option.

A main "concern" on AC2007 was that Microsoft elected NOT to include a way to set Trust Center settings, and I had to find a way to "hack" each users registry to get the runtime to run at all over a network.

Does AC2010 Runtime include fixes to what many thought were shortcomings in AC2007 runtime? or are they practically identical?

Thanks for your patience with me.
0
 
bcreenAuthor Commented:
Not sure where you got that I put the error trapping code into 100+ MDBs in 23 minutes -- it took WEEKS.
The only thing I've  ever dragged and dropped were controls onto forms and reports.   I'm a coder ... for 40+ years.  Coding and compiling are second nature, not a novelty (same for compact and repair).

I really like your advice about building new blank databases in AC2007 and importing.  Doing this DID clear up a stubborn, otherwise unexplainable, issue in an MDB just last week.  In that case, FEWER references existed in the newly recreated MDB. One reference that was gone, was a calendar control that you mentioned (or mentioned in the article(s) you provided links to).

Thanks so much for your thoughtful guidance.
0
 
bcreenAuthor Commented:
Email and other electronic communication is a poor substitute for face to face communication which is rich in body language, facial expression, and voice tonality.

One reading this exchange might pick up a hint of condescension, but I prefer to believe the expert was nothing but professional, sincere and competent in his attempts to help me with these problems.

I REALLY appreciate the help!
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Sorry ... the way your post read was that you had followed the advice in my earlier comment and added error handling during that 23 minute interval. I apologize if I came off as anything except a bit comical - albeit somewhat poorly :).

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.