Access 2013 runtime and SP1

Hi,

found a solution:

My Question

"in this thread 

http://answers.microsoft.com/en-us/office/forum/office\_2013\_release-access/access-2013-runtime-and-sp1/db6345d8-236f-498c-a5e1-263ebc5843b1?page=5

you are talking about how to get the Access 2013 runtime to work.

Is there a solution (by now - or do I just don't see it) that my Access is version 15.0.4615.1002 - but the runtime you can download is still the SP1 verison 15.0.4569.1506.

I am not able to downgrade to this version - I have tried to do so, but when Office 2013 (Plus) installes again, it's directly updated.

Consequently I am unable to create adddE files. I have installed Access AND the runtime as well on my PC: I can not even open the accdE (wrong version number)

Sorry for the support question, but searching the web and MS forums there seemd no solution - yet."

This email reply seems to have solved my problem:

"As far as I know the 2013 SP1 runtime has been fixed. I might be wrong, but I seem to remember hearing that. Don’t expect the runtime version number to match the full version. That rarely happens. Just get the latest one.

Installing both the full version and the runtime on the same computer is a big mistake. I strongly advise against that. If you are testing to see how a database will work under the runtime just create a copy of the file and change the extension to ACCDR."

Reply was from  Bill Mosca, http://www.thatlldoit.com/

What I did:

"THANKS for your reply. I removed the runtime from my development PC - and - all of a sudden - it seems to work!

On a test (virtual) PC (Win 7, 64 bit + 64bit Access Runtime) I was able to open a version which I had created with a 64bit version "full" Access. I did not try to create a 32 bit version (as I would need to install Office 32bit on a virtual machine for testing first) - but I guess it would also work."

Olaf

Hi

this does not work! I got version 15.0.4615.1002 with the click to run update - and the Access runtime is older!

Olaf

Fantastic news!

Question, will this be issued as a Microsoft Update as some point for users with the previous version installed or will they all have to download this manually?

Quite sure the case here is unchanged.

The runtime folks do NOT get some update and it is ignored. As noted the runtime not being updated was the issue here.

So the runtime was “never” updated here. What occurred was Access developers with the full version of Access updated their machines to sp1 (or allowed windows up to do this for them).

Then they rolled out that front end to machines had that are not touched nor updated.

So I don’t believe sp updates roll out to the runtime.

So YES – quite sure you have to update those existing runtime users to SP1 by having them download + install the sp1 update provided in the link above.

If they are running full version of Access then they should receive the sp1 update automatic.

I suggest one create a runtime install with the SP1 update included.

The issue of course is that right now for a new install the user has to install both runtime and also the SP1 update – both can take extra time and hassle to install.

How to include SP update is outlined here:

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

The above is for Access 2010 runtime but I assume this should work for the 2013 runtime also.

So this could be some work for existing installs (they have to download + install sp1), but having a "handy" copy sitting on a folder or wherever that folks can use for additional runtime installs without having to seperate install SP1 certainly makes such installs a lot more smooth.

Best regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

Not sure I should get involved with this thread, but I think it needs some clarification. This problem can happen with ANY library referenced in your application, not just the Access library. The machine you compiled your app on needs to be 100% in sync with EACH user's installed libraries. Since I find that to be either impossible for me to achieve (using who knows how many VMs) or way more trouble than it's worth, I distribute my apps in the decompiled state. That forces the users' system (with their version of the libraries) to compile the app and everything is hunky dory.

That is great until some other app installs an incompatible version of a library you referenced. (In the old, old days, this situation was very common, especially with OCXs, and was called DLL ****.) Then you have to unravel/deal with the incompatibility, hopefully(?) just by having the problem user recompile your app from the original source.

All this reinforces the idea that you should never add a library to your references list unless you really, really have to use the library.

I'm taking Albert's suggestions seriously here, should have an answer by Monday whether or not his claim truly rectifies the issues. But the fact is, what Albert assures us is "common" knowledge is far from that.  Again, I've been at this hard core for 15 years and never even remotely ran into anything like this issue, despite Albert's assertion that of course I have, I just didn't know it. 

Yes the point stands:

You deploy to a different version (binary) are you are asking for trouble. As I pointed out we had this last year with 2010, and as I pointed out we had this issue back in Access 97.

I think the “emergency” solution would be to deploy a front end with source code. You can even rename this FE it as accdr. With that extension the application will launch as runtime with design surfaces locked up – note that Access is smart enough to detect the binary difference and WILL RE-COMPILE your code for you! – this occurs EVEN with runtime only – the VBA compiler is available). You long time developers here all know and realize that you code will re-compile on the clients machine in this case – correct?

Another solution?

 (this is what I used last year when the 2010 sp update broke runtime applications).

I created two front ends – one for sp1, and one for non sp1. So if the first install did not work, people were told to install the second choice. So I simply had folks run the non sp1 until the SP update came out.

Note that NOW sp1 for 2013 runtime is available? I suggest to all to “include” it in their runtime install as to eliminate the need to install a separate sp1 update.

The REALLY big mess up here was that installing sp1 to an office install did NOT upgrade the runtime and that certainly what messed “most” up here.  And as noted we had this issue last year with 2010 runtime.

The issue of course is that auto updates DO NOT modify the runtime! This is actually GOOD THING and GOOD choice by the folks in Redmond because as a developer I DO not WANT Microsoft updating my client’s runtime and that seems to be what most here would agree with.

In other words your runtime installs WERE NOT updated by Microsoft update.

The problem here was not some un-scheduled update of the runtime, but in fact that runtimes ARE NOT updated.

The problem here is YOU DEVELOPERS HERE let you development machine be updated to SP1 – and then started deploying software to machines without the SP1 update. (and I think we can call everyone developers here – right?)

So in summary:

Most simple “quick” solution – deploy new front end with source code.

Next most simple:

Deploy new front ends without SP1.

(maintain two versions until all are running sp1 updates)

Last year when in a hurry and busy and the 2010 runtime had this EXACT same issue – I simply re-compiled a non sp1 front end, placed on the server and had those unable to run that package. Of course I wrap all my installs in an inno install. I likely should have it check the sp release during an install.

Best regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada