Access 2013 runtime and SP1

Thanks Albert.

The first question I had was "How can I tell what version I do have?" and found the answer here:

What **version** of Office am I using?

Following those instructions, I have found that my version is "15.0.4601.1000" (32 bit - Office 354 Home Premium) and is set for Auto Updates.

I inspected the properties of the 32 bit version of the runtime (AccessRuntime_en_us_x86.exe) that I downloaded very recently, and found it to be version 15.0.4517.1004

(Microsoft says this file is dated June 28, 2013)

Sooooo... is that a "mismatch"? (I think so!)

My clients PC is not here right now, but here is what I had to do to get him up and running.

1.) uninstalled Access 2013 runtime

2.) installed Access 2007 runtime

3.) copied the ACCDB versions of both the FE and BE file to his machine.

(I kind of trust this customer with the ACCDB front-end because he has been a loyal customer since the days of Access 2.0) He is running this PC in tandem with the WinXP/Office97 as a bit of "beta testing" until we go live with the Win7/Access ACCDE. This "new" PC of his also has Office 2010 installed but not activated. (Yikes!)

So far ... it seems to work.

I have Access 2007 AND 2013 on my PC at home, and it appears that either version can be used to open the BE.

So who knows which version I used to compile it?

I'm "pretty sure" that I had done most of the development in 2007 because 2013 refused to open/convert an MDB file.

I was also disappointed to discover that MS has discontinued the deployment wizard in 2013.

The bottom line:

Yes, I have been using Access for a long time ... but I'm a "hobby" programmer, not a pro ... so most of what you said was either new to me or forgotten.

(yup - grey hair tends to cause that!)

Thanks.

Don

The simple solution here is to ensure that you and your target machines are matched SP levels.

That means you should NOT be un-installing SP, but re-deploying your front end and ENSURE that the machines have SP updates that match your dev machine.

Even back in Access 97 days it was ALWAYS a VERY high risk adventure to run your compiled applications on a DIFFERENT SP release as your client’s computers. You are in effect running a DIFFERENT version of Access with different .dlls etc. We talking thus about software that miss-matched.

In fact EVEN way back in Access 97 days I was answering a question about ONCE PER WEEK in newsgroups which was a result of broken references. The simple fix which I had TO REPEAT OVER AND OVER LIKE A BROKEN RECORD was to install the updates to office (SR1 and then SR2B for office 97). You THEN had to install the jset35sp3 update.

So the idea being floated by some people here (who are claiming supposed long time Access experience) that this is some how a new problem or issue is not the case at all.

Anyone with ANY AMOUNT of REASONABLE ACCESS EXPERIENCE would know the above. The idea that you compile and then release your compiled application to a target machine running a DIFFERENT sp release of ANY KIND of software is simply not going to work and is a high risk adventure.

So the idea that this issue is ANYTHING new here needs to be instantly tossed out.

We had these issues with VB5 to VB6

We had these issues with .net updates – you cannot run your .net software using different runtimes either.

We had such issues with FoxPro

We had this issue with Access 97

In fact we also had this issue with Access 2010 last year.

http://social.msdn.microsoft.com/Forums/office/en-US/75d4521e-401f-4208-9567-07a6a2b579c9/ms-acces-2010-runtime-with-sp1?forum=accessdev

So in summary:

For the last 50 years of computing, when you deploy software, you need your compiled software to MATCH the deployed .dlls and binaries on the target computer.

This rule applies to most computing platforms – not just Access. This is like a mechanic knowing that cars have tires. This is a basic survival tip no more then stating that we need water to live.

So as a basic computer knowledge that those here have to learn?

One REALLY (but no REALLY REALLY REALLY!) needs to ensure that you deploying software that has been compiled with a set of development tools that MATCH the target computer set of binaries and runtimes of that given software system.

You wander off this road, and it really don’t matter what development tools you are using – you run in to HUGE AMOUNTS of trouble and you do so EVEN with .net. This is a “basic” computer skill and knowledge required by ANYONE who claiming experience with computers.

So one needs to ALWAYS deploy SAME version of your compiled software to a target machine that MATCHES the same release level of software. And EVEN Access developers had to ensure this WAY BACK in Access 97 days.

As noted, In the case of runtime deployments, the best solution is to INCLUDE the sp update to the runtime. This not only ensures that your runtime has the sp update, but also saves a LOT of time during the install since installing a SP update can be a real pain and is a SLOW EXTRA step after installing the runtime.

Even worse is as noted some might have full version of Access and that installs the SP updates, but with runtime only installs such updates are not. And note that both runtime Access and full edition CAN NOT EXIST at the same time on one machine (we talking same version here).

So only ONE copy of Access of a given version is allowed to be installed on your computer. While you can attempt to install runtime on a machine with full version of Access, what occurs is a “fake” install and some entries made so you see the “runtime” in the list of installed programs (but full version of Access is ALWAYS used in this case if full version exists on that machine).  The runtime version does NOT install in this case. You thus cannot as noted install BOTH full and runtime on computer in this context -this setup does NOT exist.

So as a developer I assume one has a VM (virtual machine) that matches the client version of software, or you don’t allow sp updates to your development machine. If you going to update your development tools then at the SAME TIME you need to update your customer’s runtimes.

This is REALLY a rather VERY simple concept that all budding developers and those here new to computers in general need to grasp.

So for existing users they will (should) install the SP update to those machines. You then re-compile and re-deploy your new front end that matches the target machines.

And I do suggest one include the sp updates in your runtime deployment. How to do this is outlined here:

http://www.mockbox.net/office-2010/417-office-2010-how-to-include-service-pack-1-slipstream

I been using the above for 2010 runtime since the day the SP update occurred since like even back in 97 days, and now in 2010 days, I simply had issues with target computers thus running a different version of Access.

As noted I consider Access versions with different SP levels of updates to be different versions of Access and this was cleary the case back in Access 97, Access 2010 or now 2013.

So even in Access 97 days I had many problems and often compiled applications would NOT run correctly and often this was due to the target computer not have SP updates installed.

There is no new magic or new computer information here required beyond that basic knowledge that one needs to avoid mixing and matching deployed software to different "binaries" that are a result of users installing different versions of software, upgrade to new versions or as in this case allowing SP  updates to those target computers.

Best regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

Bill,

I see what you are suggesting and I was not able to rectify all the problems through a restore before that update.  BUT... I thought I'd investigate what you are suggesting and I don't see "Microsoft Office 2013 SP1", or anything related to Office at all on any of my machines under the "Uninstall an Update" list.  Does that make any sense???  For some reason, office is not appearing in "Installed Updates" on any of my machines.

UPDATE: To keep this thread going, I am still have some major "Issues" even though I converted all my machines to full Access.  I am able to at least run my database in runtime mode with and .accdr extention on all my computers if they run full Access BUT I am getting major corruption issues as soon as multiple people try accessing the back end of my database.  I am in the throws of troubleshooting that, but reimporting tables and the like does not appear to solve the problem. I suspect this update is causing major sharing violations in the local tables when the database code is executing.  These issues were not present before the update.

The database run flawlessly when only a single user is accessing the back-end. SO long story short, my present work around of installing full access may does not fully be solving the problem. I am not ruling out design error on my part at this point, but I have not made any major design adjustments that would be affecting concurrent user violations, and the result is database corruptions, not general usage errors which implies microsoft issues.

Go to the Control Panel. Select Add/Remove programs (windows XP) or Programs and Features (win7).

When the dialog box opens be sure to check the box to show updates (winXP) or click on View Installed Updates in the left frame (win7).

Find Microsoft Office 2013 SP1 and uninstall it.

JuanMas53 do you think you can give detailed instructions on how you uninstalled the update? Thanks.