Download Access 2010 Runtime, Database Engine Redistributable and Source Code Control

To: Alan Cossey I see that you wrote: "With regard to my problems with Access 2007 full version yesterday, a full re-installation of Office 2007 solved the problem, leaving me with both Access 2007 working and Sharepoint Designer 2010 RTM working OK as far as I can tell. I'm not going to try to install Access 2010 runtime on this machine though." Are you still having a problem with CurrentProject.Connection? I had some time available to play with this, and I am able to replicate errors if "Unsafe Expressions" are blocked and I attempt to use this in a query. I get "Enter Parameter Value": SELECT CurrentProject.connection AS [Proj Connection]; or I attempt to set the Control Source of a textbox on a form to use this expression (I get #Name? error): =CurrentProject.Connection However, even when getting these errors, I am able to get this information from the Immediate Window ( ): ?currentproject.Connection Note that I get these errors even if I click on "No", on a dialog box at startup that reads: "Security Warning: Unsafe Expressions are not blocked.

Do you want to block unsafe expressions? Yes No Help" In fact, if I have Macro Security set to the default of Medium in Access 2003, I am unable to get CurrentProject.Connection to work in either a query, or as the Control Source for a form (even with Sandbox set to the default of 2). I'm not running Access 2007 right now, so I cannot test that at the moment. Tom

@ Michael said: I am 100% on your view that this has always been a tough issue and a big shortcoming of Access. As mentioned, it not really an issue of the runtime as much as access and how it is installed. The runtime not really any different then the full edition. The trade off here is that the spell checker and all kinds of bits and parts like EVEN the new ribbon customizer is a shared component of office. Even the native PDF support in access 2007 and 2010 comes from that shared office library. The amount of shared library code is really quite large here. That levering is great feature because we thus receive so much functionally as a reasonable cost. And the feature set is spread over the office products. For example, a upgrade from previous versions of access to 2007 is only $109. So you get a lot of bang for the buck this way. The tradeoff is that dependence on the other parts of office. The runtime not intended for commercial distribution of your application, but was made available for those computers in the office that don't have ms-access installed. So the need here always been more of a inward facing solution for a company, not commercial free distribution for applications. @ Michael said: > The solution wouldn't have to be any more complex than the Sagekey solution Sagekeys does a great job. I suspect they had about 4 people working on that product. They have been doing so for about 10 years now. So that still does represent about 40 man years of developer time. That still thus represents a major chunk of the access team for one year. I was involved in the beta 2010, and there was lots of features that were cut. So, budgets are limited. They would have to near give up a whole product cycle release for just this one installing feature? And out of 100 access users, how many are packaging their applications for commercial distribution? And what is the return on investment here? How long would it take MS to receive it money back for this large project? I mean you have 40+ developers work on for a year or so for something that only 1 out of 100 access users plan to use? Do you really think that this free runtime system would increase sales of ms-access so much to offset the cost of those 40+ developers? It might even result in a drop in sales. It is no small undertaking to setup a installer system that will work for the 30+ different languages and localizations around the world. And that system has to be fully tested and supported for windows XP, windows Vista and windows 7 and also server 2008. So, no this is not easy task nor small issue of resources at all. If this was such as easy task then the access developer community would have cobbled together some solution years ago. I mean Stephan Lebans built a PDF system for us. I used his solution for years until access 2007 came along and it now has PDF built in without needed any other software or even a printer driver installed. However, no one has attempted to build a trouble free install system. The above explains why. Even the above access 2010 runtime includes pdf support (without any additional download needed). So, this is clearly not a simple issue nor is there a simple low cost solution. However, I DO THINK there is VERY simple way around this issue. That solution would be using application vitalization (AV). It just so turns out that Microsoft owns some AV technology and products. The current use of AV is for streaming applications to users on Terminal Services. This exact same technology could also be used to create a AV edition of the access runtime. This AV edition of ms-access runtime would instantly give a trouble free independent installed version of the runtime (in fact, there is no install, just a .exe that runs). Even better is the current EXISTING office installer could be used to create that AV edition of ms-access. So there is a future possible way to do this. The only issue stopping this is Microsoft has not yet released a version of their AV system for developers to package stand alone solutions. However, the one-click office trials were using this AV technology. If you not seen this, you can try office 2010 using one-click, and it WIL NOT disturb your existing office install. It is a VERY cool technology. And, the office install ONLY streams down to your computer the parts you need. So, you can darn near start using word right away without any install problems, or even only a small part of office having made it down to your computer. So, AV technology holds the best approach for a true standalone .exe version of the access runtime. If Microsoft ever releases a edition of AV for developers to create stand alone .exe, then you could run your access application off of a jump drive on ANY windows computer with ZERO installing issues and zero conflicts with the existing version of office on that computer. In fact, this setup would work even on machines that are locked down from users being able to install software. So AV is a possible ticket and ride we are looking for here. What is even better then is we would not have to see like near half of the access developer team taken out for a year or more that represents a huge part of a full product cycle release to create some installer that 1 out of a 100 or 1 out of 200 access users wants. And, there is the big question of how creating this installer would off set the cost and pay for this large project? In fact, the project might even reduce access sales. So, I think the best cost play here is not to spend money on building a installer system, but to simply use Application Vitalization to solve this issue. Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

kallal@msn.com

Albert your comments are good in general and it will be interesting to see if anything comes of AV re Access deployments. I agree that MS has to balance the books re where to spend development time. Clearly, they have been showing us that building what we Access devs have been asking for over the years is not the pot of gold at the end of the rainboq. Something to do with sharepoint (that non-relational list server) must seem like that p.o.g. It's plenty clear at this point. I have quibbles with two things you wrote. One, I am sure that the runtime was created in part so that one could distribute commercial apps. It's been done all over the place, Microsoft knows about it and is ok with it. Two, the sagekey solutions sure didn't take 40 man years to code. They put in a lot of effort for version one, and since then it's been maintenance and incremental mods for each version of Access. There have not been four coders banging away on the product for ten years. I would guess that the community could in fact build out a solution like sagekey, but it just hasn't happened. One reason might be that many of the best Access devs get tired of the limitations of the tool and move on to .net or whatever. So they're not 'with us' any more. Think about all of the Access community power hitters from a decade ago - a few are still around but a very large number of them quit the scene. There are a lot of good rad tools for distributed app development out there now. This is a very rich time to be a custom solution builder. Access from it's first incarnation was such a great leap forward in terms of productivity...yet it's not kept pace with things, was neglected by Microsoft. At least until it's recent manifestation as sharepoint client. I always hope that maybe Microsoft will pull off a version I really like, and 2010 is ok in some regards. But it's not the Access of my dreams. I really cannot fathom why Microsoft has not build something as productive as Access that is inherently net enabled. Wouldn't anyone see that as a huge hit with developers? Microsoft is the company that could have done it; they've got the skills and the core technology that's for sure. In addition, Microsoft has been the best at supporting power users and the hybrid developer/business consultant. So many things I don't understand .

So, SCC is 32-bit only. Are there any plans for 64-bit SCC?

>Something to do with sharepoint (that non-relational list server) Well actually the new SharePoint does have relational features such as cascade delete restrict and even now has cascade deletes. So it relational now. I also think that the way Access can now go offline + online mode and sync the data onto your desktop is great. As for the 40 man years? Sure that is a rather high end view. However the fact that you're saying version 1 came out in X amount of time really doesn't represent the total investment over time that's been put into the product. I mean one full time developer over 15 years still represents 15 man years (and that product been around that long or more). The original installing product they had was rather simple, compared to the very polished and advanced system that they've written and built up over the years. If you don't think the investment is that great of an effort, then just go out and get a few developers together and build a product and then go sell it for $99 and see how well you do. In other words put your money on the line here. The problem will NOT be your $99.00 price. The problem will be in your expenses and cost of development for the kind the revenue you can get by building such a product. The average large city has several hundred yellow pages of development firms. Just pick up the phone and get on this. All is I'm saying I've been in this business long enough to understand that it represents a sizable investment. It is not cheap. As for investment and development into ms access and keeping up with the Jones? I have to give credit where it is due. From a developer's point of view we are quite fortunate to see continued investment into the product. For Access 2010 did get a new version of VBA (version VBA 7). This new version of VBA gives us 64 bit support and some new data types. In addition to the 64 bit edition of VBA, we also get a 64 bit edition of our database engine. I mean the folks in Redmond could've used the 64 bit issue as an excuse not to invest in the product, but in fact we saw the reverse occur. And speaking of the data engine, it great to see new investment into our lovable desktop database engine. I am hard to pressed to think of a desktop database engine that has support for both stored procedures and triggers without any kind of server. I believe some file based engines do have some triggers, but I'm not aware of any that also has some type of store procedures like the new version of JET (ACE) does. (anyone care to correct me on this???). Those triggers even fire when ms-access is not installed. You can open up a accDB file with odbc, or .net, and those procedures will even run. And, we do have the ribbon that was most certainly the envy of other developers from FoxPro to VB6, and even .net developers. MANY were resorting to third party tools until later editions of visual studio came out with some tools for them to build their ribbons. I not saying everyone ran out to get ribbon tools, but a good number did, and we Access people never had to do that. Another area that's really improved for client development process is our great new navigation control. Along with that navigation control is those WEB style buttons. I mean it's about time that we got support for transparency, and things like round and shaded buttons. All of these features work great for desktop only applications. Access applications where starting to look old, and with this update, my applicaons now again look modern and fresh. Applications are never all look and feel, but this aspect is important for my applications. Among my favorite new feature in Access 2010 is the new web browser control. This allows me to display pictures or just about any content from any web site with great ease. Throw in the native PDF support, and again the list of great usable features by Access desktop developers just seems to keep growing and growing each year. I've only touched on a few of the new developer oriented features, but it seems to me that the continued investment into the product is a really great thing. A good number of these investments are benefiting client desktop developers a lot here. And as for competing with the .net people?

Well, I do think it is slick that we're now able to develop and deploy web based applications. That itself is also a whole new area that's opening up a lot of doors for Access developers. The fact that as a product Access is now making inroads into the web based world of things again keeps the product up to date and means we join the web party. I don't want to stand here and sugar coat some of the shortcomings. I think we both well agree that deployment is an issue and shortcoming that we the developer community should continue to point out, and also to continue to ask for improvements in that area. I will continue to mention this issue to the Access team when ever I get a chance. On the other hand while I'm most able to point out some of the shortcomings, when I look at the host of features that I can use for the client desktop development side of things, there's a lot of compelling new features in 2010, and that simply means that as an access developer I can continue to look forward to doing great new things with the product we've all grown so attached to over the years. Albert D. Kallal

Edmonton, Alberta Canada

You're right about relational to some extent anyways. My comment about non-relational list server was rather knee jerk; years of habit overriding the mild interest that I feel about sharepoint now that it's got some kind of relationship technology built in. I know of that - and just got a sharepoint server configured a day or two ago. I've not had time to explore what they mean by relating lists yet. I am sure it's a lot better than nothing. But it's not a RDBMS for certain. What it is, I don't know yet. The stuff I do for clients needs something on the order of postgres sql server or oracle on the backend, and I am not sure what impact sharepoint's new relational aspect will have on it as a viable option for use here. A lot of deep, heavy duty work has gone into data integrity, performance and many other RDBMS tech topics for those RDBMS; sharepoint will be quite different. Different tradeoffs, different pros and cons. As far as I know, I would still never chose sharepoint as a backend with all of those excellent RDBMS out there; but it may be of use for some clients, for whatever reason. In other words, it appears that sharepoint 2010 and Access 2010 might be good enough together to make some nice music...I'm glad of that. I know you're a fan of the new versions of Access. I know they've added some useful stuff. But as has been rehashed here many times, many parts of the product have veered off course for many of us who have been most devoted to Access. I do like 2010 better than 2007; I have no idea yet if after really working with it I'll adopt it as a development platform. All the conjectures about sagekey and how hard it might or might not be for Microsoft to make the runtime installs more isolated is irrelevant to me. What does matter is that the out of the box Access runtime installer still carries with it the risk that by using it you risk torpedoing retail installs of Access. Re what would it take to make it pay for the Access Team to really fix this issue, who knows? Frankly I have not been too vocal on the issue because I don't see how the runtime pays them period, much less investing further in it around the installer issues. If I say "the runtime is problematic" too many times, they might turn around and say "you're right, and we've decided to discontinue the runtime project going forward". Oops!

Tom,

You asked, "Are you still having a problem with CurrentProject.Connection?" No, I'm not. The complete re-installation seems to have cured the entire problem, even with SPD 2010 and the Access 2010 runtime installed. Prior to doing that re-installation doing ?CurrentProject.Connection.ConnectionString in the Immediate Window was crashing Access, but it is OK now. Alan

Ha! Now I can't uninstall Access 2010 runtime prior to installing Office 2010 Professional Plus RTM. When I try to uninstall the runtime from Control Panel it tells me,"This product installation has been corrupted. Run setup again from the CD, DVD or other original source". When I do this I get "Setup has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available." There is none.

Alan, that sounds rather grim. I may have time to try out the runtime and then attempt an uninstall later today on a vm. I was going to try out the runtime on a regular workstation that does not have retail Access, but maybe that'd be a bad move till we either hear that that's an Alan only 'special', or if the issue is more widespread than that. I'll post after I've made the experiment.

I work at a company that produces a 64-bit (AnyCpu really) desktop application. We were hoping that the Office 2010 drivers would enable oledb access to mdb and accdb files.

Unfortunately, the inability to install the 64-bit drivers side by side with 32-bit Office has left us in a position where we are no better off than before since our corporate customers will not go to the unrecommended 64-bit Office suite and lose 32-bit drivers used by other applications.

This decision just seems crazy - it would be interesting to know if it's artificial or if there really is an underlying technical problem. Pelle

Great to see the availability of the 64bit version of ACE, did anyone manage to pull it off yet? I am using Excel 2010 (64 bit) and installed the new Access Database Engine (64 bit). I performed an oledb IDataInitialize->GetDataSource(...) call from my C++ app with a connection string of the following form: Provider=Microsoft.ACE.OLEDB.12.0;Mode=Share Deny Write;Data Source=path_to_excel;Extended Properties="Excel 14.0;HDR=Yes;IMEX=1" Always got Class Not Registered back as the HRESULT. I tried switch the connection string back and forth using Microsoft.ACE.OLEDB.14.0 as the provider or Excel 12.0 for the extended properties but none works. Am I missing anything here? Thanks!

Alan fyi I installed the Access 2010 x86 runtime on a windows 7 x86 box, ran an application, and then via control panel uninstalled the runtime without error. Did you previously have any Office 2010 beta software installed on the machine you had issues with? What OS?

Will there be a version of the source control add-in available for 64 bit at some point?

Absolutely agree with Pelle!

Impossibility of having both x32 and x64 versions of ACE on the same computer makes the whole thing for us useless. We are developers. How Microsoft thinks our users will be installing software that we provide to them on Windows x64 when ACE installation may have conflict with other ACE-based applications and even Microsoft Office itself depending on whether x32 or x64 applications are already installed!?

Unfortunately for ourselves we are still stuck with old Jet 4 x32 and tricks that we use to link it with 64-bit release of our application.