You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
There has been a series of questions on the Access blog and in the newsgroups about Access’s future as a tool for developers. Although it is WAY too early to nail down what we will do in the future, I can share a bit about how we think of Access going forward and our longer-term goals for the product. Access has become the most broadly used database in the world because of 5 key strengths: it is easy to author and allows users to get to a running solution quickly, it combines the power of a real relational database, rich forms & reports and code for developers, it creates single-file solutions that are easy to manage, and it has rich connectivity to existing data. All of these strengths will continue to be important in the future. In addition, we believe that the ability to build rich client / rich server apps will become increasingly important going forward, as customers increasingly seek workgroup solutions that work over the web.
You could think of Access 12 as focused on two big areas; first becoming much easier to use and faster to create a useful solution, and second, on creating an interesting new class of applications on Windows SharePoint Services. The ease of use and time-to-solution work is really related, and we worked hard to achieve this by making the features easier rather than dumbing them down. Access’s designers are all 10+ years old (I mean the tools in the product, but come to think of it, all the people working on Access are also 10+ years old), and the technological changes over that time have allowed us to do stuff we couldn’t have dreamed of back in the early 90s. Direct manipulation, live data at design time and many of the other features in Access 12 would simply have been too slow back in the day, but they work great on today’s machines and modern Windows. In addition, Access 12 blazes new ground to enable applications with both rich and reach clients against SharePoint that were super hard to build before. We think there is a big opportunity here, both in terms of the type of applications that can be built, and the ease with which IT can manage those apps. We believe this work is useful for all of our users- developers, end-users, and IT folks; but we also believe there is a lot of other work that remains to be done in the future.
Access aims to provide three things for developers going forward:
We continue to believe in Access as a development tool in a big way. We think that in the coming versions Access will continue to get faster and more powerful to develop in, that it will enable new types of applications, that you will be able to extend your apps to new types of servers, and that it will be possible to extend Access apps with Visual Studio when needed. We’ve made progress toward these goals in Access 12, and believe that Access 12 is the biggest improvement we’ve made to the product in memory. We also believe that there’s a long way to go and a ton of interesting work to come in future versions. We’d like you to come along, and take advantage of Access 12 and beyond to build some killer apps.
Comments: (26) Collapse
As someone who uses Access day in and day out, I am interested in the new features that you are introducing. You mentioned that Access will continue to be a good client for SQL Server. I was wondering if you could comment about if you can Access will be able to go above and beyond basic ODBC connectivity to other features in SQL Server 2005?
Erik's comments on the future directions for Access are reassuring. As a long-time user (since A2), I'd like to build A12 killer applications for my clients, but they just won't pay for upgrades when they have stable A97 applications that do everything that they need. This has always seemed the key paradox to me. I think the only factor that will catalyse a change of attitude is greater use of the web, but in rural South Africa, where I live this could be a long time away, given the attitude of our telecomms monopoly to broadband product pricing. But, hey Erik, it's good to know that Microsoft sees a future for Access. It's a killer product!
OK, OK, so we have given you a hard time. But lets get this on the record: 1. Is the feature set closed for Access 12? 2. There is a rumour of 'developer extensions'. Are these being considered for Access 12, or is this the first hint of Access 13?
I really do not see so much innovation here. As developers we do not care to see sample application prebuild and a lot of wizard for building standard form and report, since we are developer and we want build our form. SharePoint integration: there are a lot of MS access developers oriented web site and not any developer was requesting this integration: what about adp to Oracle or DB2, what about real VSS integration, what about dividing form and report, not to mention the VS integration. I'm really happy that finally someone in MS is taking care of Access, but I feel developers are not in the goal of this release as they were not in the last 3/4 (since access 2.0).
Committment to the future would include OLAP and Cube creation support.
I'd love to see the languge support issues figured out.... :-)
I'm delighted to see the huge commitment to Access and the focus on getting more people to use it. Microsoft has neglected the huge installed base of Access users and developers for years, so the new investments are very refreshing to see. Access is ideally positioned to fill the gap between Excel and database solutions requiring more sophisticated development. As a user, developer, and owner of a firm deeply invested in Access, I think you're on the right track. Making it easier for Excel users to create database solutions is the first step to creating a larger Access community. As for developers, I think the features of the enhanced table format of multivalue fields and supporting PDF files will allow us to create new solutions more easily. I know some developers want to see .NET added to Access/Office, but from our perspective, that would be like throwing away the programmability of Office since most Access/Office end users will never be able to make the leap to learn it. Focus on the needs of the information worker and Access will be successful. There must be 100 or 1000 to one Information Workers to .NET developer. Luke Chung
President
FMS, Inc.
http://www.fmsinc.com
Thank you for the reassurance and the details you have been able to give.
We here know how really good Access is at doing so many things that would take ages with other tools and that it is so useful in turning customers' ideas into reality. Will there be any certification for Access developers in the future like there was up to and including Access 95? It would make convincing potential customers that Access could be a good solution for them that bit easier.
1) I still don't understand how SharePoint fits in. The trial sites on the MS website are very primitive, and don't seem to do anything useful. Erik, can you give us some working examples where SharePoint/Access is a good soluton for a real and complex problem? Why use SharePoint over SQL Server directly? 2) Luke, I am a real fan of you and your company, but I have to disagree about .NET. The only reason it seems more difficult is that it does not natively support the familiar Access object models and special commands (DoCmd, etc, etc). This problem is definately solvable over time. I, for one, would really prefer to work in the far superior IDE, as well as having access to the other features. 3) I totally agree with the rich client/"server over web" model. Unfortunately, the Slammer worm as scared most of us away from doing this with SQL Server and Access. When will it be safe again for Access to connect a SQL Server directly over the internet? Or, are we stuck with VPNs or Terminal Servers, etc. Why do we always seem to need a very complex middle layer (Web Server, SharePoint, VPN, TS) just to get at our data safely? What happened to "Data at your fingertips?" 4) Please don't forget about automatic rich client deployment. We could really use some help in this area, with automatic detection, automatic scheduled background updates, patching, etc. Every multiuser Access database in the world could use this, and it should be a high prority. We need project options called UpdateSite (network, web, ftp, etc), UpdateSchedule (hourly, daily, etc.), etc for super easy deployment and maintenance. The deployment should be able to handle developer-definable accessory files, as well as the mde, ade files.
I have been building apps full time for clients using Access since version 2. Access has been pretty good to my clients and I despite the almost complete derth of significant improvments since Access 97 (that's a long time ago!). I am glad to have found this blog but am very dissapointed by most of what I've read about the next versions of Access. As others have pointed out, it's not Access developers that are asking of Sharepoint integration. That focus for the new Access must be a part of some agenda that corporate Microsoft cooked up to hopefully make Sharepoint some kind of killer app. The Access team has been given much more juice in order to help pull it off. But it's not what devs are wanting AT ALL. I'm guessing that Access was left adrift for all these years because Microsoft didn't want to make it so productive that it'd take away sales of VB, and now .Net. Since Sharepoint integration is a bit off the direct beam of .Net, Microsoft must feel this is the place to drop the Access bomb. I'm really sorry about it because I just love how Access works. It's super productive for the right kind of project. The overwhelming desire that I hear about from Access devs is to get a modern interface to SQL Server, something beyond ODBC and deadmeat ADO. That does not seem to be in the cards at this point. Eric was polite, but mentioned nothing at all - nothing - that I as a full time Access dev find encouraging or interesting. Funny I was thinking today about FoxPro. When it was bought by Microsoft, all of the Fox devs I knew were just crushed. They knew Microsoft would backburner it and expected it to fade away. Well, strange how things turn out, it's not anything you hear about, but because it's *only* a dev tool, it keeps getting real dev level improvements to it (or so I gather from what I read). Because Access is a component of Office and is often used by non-devs, it's never been taken seriously even by Microsoft; or perhaps, Microsoft made sure it was never taken seriously because an improved Access might damage sales of other Microsoft products. Me, I'd pay some real money for a real developer version of Access. But, no one that matters is listening to people like me.
Access is a serious developer tool ? we have our answer. We’ve developed with Access (since A97 version) a complete E.R.P. solution with CRP (linking MS Project), MRP, and OLAP (with A2000 OWCs version) and other goodies for our customers. All business entities are mapped with VB6 objects and the business rules are methods of these objects. The Access user interface usability, the light and fast report writer and its integration with other Office products like Word and Excel are our key elements for customer satisfaction. With growing customers we linked our Access solution with SQL2000 (a well designed/normalized db avoided us all performance problems). So now we have an ERP solution with the best of user interface (Access) and the best of RDB (SQL Server). Years ago we implemented in our Access solutions many of the cool news that we’ve found in Access 12 : left docking menu by roles, docking forms (with all inner docking and resizing controls), and others that we didn’t seen on these A12 blog : contextual menus, automatic release upgrade etc. with a fraction of development time than other VB6/NET solutions but with the same result. And then what’s the problem ? The problem is that Access is a good tool for developers and for final customers but not for most IT Managers (so many developers have to mask the Access origin of their solutions) and these because MS doesn’t make a serious action in this direction yet. This is the problem : a good but not official tool. We hope in this new commitment. Alfredo Bergamo / www.softage.it
"There must be 100 or 1000 to one Information Workers to .NET developer." This may be true, but one must ask why a database developer would ever want to work in such an UNproductive/UN-RAD language as .NET! The Access RAD experience blows away nearly every advantage of .NET. The only good reason for using .NET for database development is when you hate your users, and you need to put your app on a clunky web site to impair usability and productivity. It always amazes me when developers think that database users prefer working in Internet Explorer. There is only one reason for preferring explorer - its a little problem called "deployment." And this is a solvable problem.
Thanks for the feedback, this is a consolidated reply. Knox - we're working with the SQL team on getting smarter about remoting more functionality to the server. Nothing to promise at this point, but it is definitely an are we're looking at. Andrew - while the feature set isn't totally closed, it is essentially closed. It takes us a long time to stabalize Office. The Access Developer Extensions shipped in Visual Studio Tools for Office last time and are likely to do so again (if not, they'll ship somewhere else). They'll provide tools for devs, and this time we're including a bunch of application building functionality we're using to build the out of the box tracking apps. These are Access apps that will make it much easier for developers to build their own apps in a consistent manner. More info to come on this soon, but this is stuff that you'll see around the time we ship 12, not "13". Fxp, Michael, & Luke - wow is there a lot of stuff we'd like to do that we haven't done yet, and this is definitely some of it. We're certainly not ready to proclaim that we're "done" building Access. As Luke notes, there are interesting questions about how we relate some of the potential work to our customer base. We have a lot of thinkng and work to do to sort this all out in the next versions. Alan - a certification program is something we don't have at this point, but are interested in. Here's what we've got to this point:
There is a program for Microsoft Office Specialist which is geared towards knowledge workers. Here is the link: www.microsoft.com/.../default.asp
The Office Specialist has a module on Access that “is intended for students and information workers whose responsibilities include the use of Microsoft Office Access to organize, structure, and manage data in organizations of every size.”
www.microsoft.com/.../access2003.asp
Since this thread is supposed to be about developers and development with Access, I'd like to suggest something relevant, even though I know nothing will come of it. Access is too important to me to not express the thought. Microsoft, what you hear day and night from the large cadre of Access developers is that they love the tool, and find no viable substitute for RAD development with Access. I have to say that's pretty strange considering the fact that Microsoft has never really treated Access as a developer tool, and that the product has been in a sort of limbo for almost ten years. Nevertheless, take it as a fact that Access remains a killer software development tool for many of us. (I'd like to note here that Microsoft does not develop applications with Access; we the people are the ones who know what it's like, what it's capable of). So here comes the pipe dream part. I would like to see a developer version of Access, one that costs a lot more and sells a lot less copies. I'd even be willing to put money into a "fund" that would pay for fixing bugs that Microsoft does not care about but which impact actual users of the product (there are many serious or just annoying bugs in Access; like the unbound labels on tab controls flicker in Access 2003 that remains unpatched through sp2. I mean how lazy can you get). I don't think Microsoft will take Access in any direction that I really like. But unless an alternate appears on my radar I'll probably stick with it. I know little of the history of the product, but I wonder what happened to the original Access team members and whatever vision they must have had? Access started out of the gate so strongly, and based on that it's still a great product, despite only token improvments for almost a decade.
Hi, I've been a consultant and an Access developer building corporate apps for over 10 years (and I'm heavily into VB.NET, SQL Server, and integrating with other office products too). A continuing problem for me has been Access's continuing reliance on ODBC connections for linked tables attaching to a SQL Server db. When deploying an Access App front end to a client's system, with the ODBC connections set to exactly the same settings on both the Development computer and the Deployment computer, the deployment computer nearly always comes up with an ODBC error, which can only be resolved by doing a relink using VBA code or the Linked Table Manager, relinking every table that has the ODBC SQL Server data store. As the alternative that I'd like to see, I'd like to be able to type connection strings directly into some kind of new setting in Access that would not rely on ODBC at all, but allow me to use a connection string builder, much like what exists in VS.NET. I understand the that data connection capability is being rewritten in Excel 12, and I think that something new needs to be done in Access 12 as well. Also, currently the Linked Table Manager provides the basic functionality that is required to relink tables, but it would be great if it had the ability to sort rows not just alphabetically by table name, but by connection type as well, since I have to do that a lot these days. Another idea: I don't know how feasible this is, but would it possible to build in support for ADO.NET and the CLR directly into Access, as an alternative for VBA? I had heard some rumblings on this, but got nothing definitive from anybody. I'll enter more thoughts as they arise. I appreciate your comments, the blogs are a great way to communicate with the developer community. Thx, Neal Miller
Miller Systems, Inc. www.milsys.com
Comments: (loading) Collapse