Access 2013 runtime and SP1

I just read that MS is working on getting 2013 SP1 pushed out as soon as possible.

Do you mean for the Runtime Version of Access 2013 (365), Bill?

WHERE did you read it? (Link, Please)

Thanks

Don

Yes, I realized I forgot to indicate runtime. Edited my post after submitting it. As to a link, sorry, can't do that. I read it in an MVP user group.

You have to realize MS has moderators in this forum. When they see a bunch of posts indicating a major issue they act on it. It's just that Access is super complex. Fixing one thing can break something else. What's worse is virus scanners can also break things after an MS SP (like what happened with Kaspersky and Access last week).

And how does .net avoid these problems? The simple matter is with .net and the CLLR runtimes if you miss-match SP updates then you have the EXACT same issues and problems here.

You deploy .net software to machines with different SP levels for the runtime (and there are LOTS of runtimes for .net) then your code and application will simply not work correctly will have all kinds of issues and breakages.

There are “tons” of issues and bugs that get fixed with .net runtime updates. If you a deploy your .net software to a target machine WITHOUT the sp updates (just like folks here are doing with Access) then all kinds of bugs, issues and failures of your software will occur.

Bottom line:

You simply do NOT want to miss match compiled binary software created on a machine with a difference version then the target computer.

YOU BREAK THIS RULE THEN YOU ARE HEADED FOR HUGE ISSUES AND PROBLEMS. The idea that .net avoids this “basic” 50+ year computer knowledge and problem is laughable on your part.

The simple soltion here is to ensure that SP1 is installed on the target machines WHEN deploying compiled software.

If one includes the source code then Access is rather smart and can re-compile automatic because it deteicts the binary version is differnt. Wtihout souce code, then the developer and target binanes simply need to match and this applies to .net, old VB6, C++ and just about any development platform that allows distribiton of comipiled source code.

Best regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

I hope you're info is correct... this would be a welcome development to say the least. Obviously my biggest concern was whether this was even on the radar or if only a select few were experiencing this conflict because of something specific to the local environment.

Great, keep up the squeaking... if we squeak enough then at least it has a chance to be on the radar for fixing.  I agree with your post about us "hobby" programmers and just expecting it to work.

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. 

You're right, I just expect the damn thing to work correctly, my business cannot afford for it not to.

This has been a wake-up call for me... once this thing blows over. I'm going to take flash images of one of the machines in working state as well as a copy of the database application and backend from that date and file it away.  Microsoft does this again, I re-flash the computer, remove from the internet, and keep my business running without a hitch.

Shouldn't have to go to those lengths but...

Shouldn't have to go to those lengths but...

No, we sure shouldn't.

Microsoft just needs to TEST and issue updates to BOTH the full version and the Runtime concurrently. Period. Exclamation Point.