Access 2013 runtime and SP1

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

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?

Hi,

For everyone following this thread, we have now published the Access 2013 Runtime SP1 to the download site. You can download and install the SP1 build of Access 2013 Runtime from this location:

http://www.microsoft.com/en-us/download/details.aspx?id=39358

The x86 and x64 installs are both available from that location.

Jeff Conrad - Access Junkie - MVP Alumnus

Senior SDET - Access Test Team - Microsoft Corporation

Author - Microsoft Access 2013 Inside Out

Author - Microsoft Access 2010 Inside Out

Co-author - Microsoft Office Access 2007 Inside Out

Access 2007/2010/2013 Info: http://www.AccessJunkie.com

This posting is provided "AS IS" with no warranties, and confers no rights.

Use of included script samples are subject to the terms specified at

http://www.microsoft.com/info/cpyright.mspx