You see the registry settings and changes made in the client are read by the ACE engine on startup. So perhaps one engine is using row locking and the other is NOT? This could rather be an issue ESPECIALLY when swapping an engine but NOT changing the client. In fact 60% is about the delta change one will experience when CHANGING from page locking to row locking. >2.If no changes were made, then a significant performance degradation must be (what?) The simple bottom line is the GENERAL community here has not taken your position on this matter. In fact to take this position would be a suggestion on your part that you are the only reasonable person here.
So now YOUR position is the ONLY claim we are to accept here? You would thus have to take the position that the rest of the Access community statements here are all without merit. If you think the “general” Access community experience is the SAME AS your 60% slowdown then you have to explain why yours is the first post claiming as such here? I have a rather good grasp of technology and you seem to be forgetting one big issue here: Was a technical editor for the Access 2010 Programmers reference and took computing science at University of Alberta. I been around on-line forums since the CompuServe days. I did not say anything about unfounded conjecture. In fact this is the first post to my knowledge. And we not seen ANY number of posts in this group (or any on-line forums) also making this claim of such a slowdown. Right now, I not seen nor experienced any significant slowdown when using Access 2013 over that of 2010.
DOWNLOAD MICROSOFT ACCESS DATABASE ENGINE 2010 FREE
If the poster has a simple data set + query for me to test/try with 2010 and then with 2013, do feel free to post that sample data + the one query. Without changes being made to the client then little reasons will arise to cause such significant slowdowns in the client. To cause a slow down in say the data engine becomes increasingly rare! While some may not think its great that little if any development is occurring in the client such a situation should be warm and welcome news to long time developers since then the probability of something changing in the client such as adding MORE features Until the community gathers additional feedback then such claims are going to be seen as unfounded conjecture that 2013 is so much slower then 2010. And I tested + seen some rather “monster” applications run in both 20 – again no big performance hit. If Access client is receiving “few” if “any” changes then near ZERO reasons for the v-next of the client to experience a slowdown also exists!Īnd to be fair here I not seen ANY widespread reports that the 2013 engine is in “general” 60% slower. So 60% is 59% above expectationsīut in this context that is a GOOD THING! Albert, you forgot that MSFT feels the CLIENT application has not really changed - a few deprecations and the CLIENT is done.
0 kommentar(er)
