Of Access the user is running to the SAME edition that will compile + develop the application. Leaves the 2010 runtime alone as it should.Īnd while I seen problems like this back in Access 2003 (by trying to run a compiled applications with 2000), the simple lesson here is that compiled applications while often preferable do require more caution and effort to match up the edition of the version
Microsoft access runtime 2010 sp2 install#
In most cases, NOT having windows update or NOT having someone come along and install office SP not touching the runtime is a “preferred” setup since then windows update, or other things will not update Access runtime and NOT mess things up. Or the SP update can be “included” in your copy of the 2010 runtime. So install of the SP update to Access runtime has to be downloaded and installed. Nor will windows update update 2010 runtime. And installing the office SP update will NOT update the 2010 runtime. For the Access 2010 runtime, the sp updates are NOT included.
So the symptom pointed out here ONLY occurs when source code is not available, and the binary parts are pre-compiled like they are in a accde.įor Access 2013 runtime, the SP updates are included. (and when I say version - different SP levels are different versions).
Thus the binary resulting machine code matches This issue does not occur when you use an accDB since the source code is included, and thus an “automatic” re-compile of the code can occur (even with runtime, such an automatic re-compile of code can occur). If your dev machine has a SP update, then you need to ensure that the target computers also have that update. The simple and basic issue here is that WHEN you deploy compiled applications, you want to match up the version.
0 kommentar(er)
