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.
Hello! I’m Erik Rucker, and I’m the Group Program Manager for Microsoft Access. I’ll be using this blog to share details about the upcoming version of Access, which we’re currently referring to as “Access 12”. I’ll be working with other folks on the Access team on these posts, and so in addition to the product you’ll get a chance to meet some of the people who are building it.
The development team for Access 12 is about 7 times as large as the one for Access 2003, and this has allowed us to do a lot of work we’ve wanted to do for a long time. Our goals for Access 12 are to make new users more successful, to make existing users more productive, and to enable a whole new type of database application built around Windows SharePoint Services. Access today is quite successful by almost any standard, but you don’t have to look far to see that there are lots of unmet data tracking needs in the world. In customer research for research Access 12 we saw a lot of people who needed a database, and a lot of frightening solutions that didn't involve one. Like the guy who kept all important issues on post-it notes until he was done, then tossed the post-its in a drawer in case he ever needed to go back. Can you imagine trying to find something from 3 months ago in that drawer?
With Access 12, the post-it guy will be able to fire up Access, select a fully functional Issue Tracking application from a new “Getting Started” page, and immediately start managing his issues. And yes, he “had issues”. No authoring required. If he wanted to start from scratch or take an issues list from Excel as a starting point, he’d be able to do that by simply typing (or pasting) into an Excel-like grid. Extending the application by adding new columns, forms, or reports is equally easy. He can then create forms and reports with a single click, and edit them in a WYSIWYG design surface far more easily than they could in Access 2003.
Existing users and developers will find a wide range of new tools to help them build their apps more quickly. Imagine the developer called in to help post-it guy. She probably won’t start from the template, but the WYSIWYG designers described above will help her create forms and reports from scratch much more quickly than she can today. Of course the existing designers are still there as well, so if she likes the current model for some tasks, it is one click away. She can use Access’s macro language to write sandboxed code, so she can deploy her solution without having to sign it. She can even make it simple for others to assign issues to the post-it guy through emailed forms that automatically upload their data to Access when they’re returned to his mailbox.
In addition to being unwieldy, the post-it solution is really single user. Sure, he could pass a note to a co-worker, but he could never track what happened to it. Access 12 can take the issue tracking application mentioned above, and easily share the data on SharePoint. The data is stored in SharePoint lists, and the Access UI connected to those lists through SharePoint’s web service. Now multiple users can collaborate on the list of issues using Access’s rich UI, or even the SharePoint browser UI. When it is running on SharePoint, the issue tracking application uses server-side workflow to do notify users when they have issues assigned to them, to manage issue resolution and so on. For the application user, this stuff just happens, but a developer can now build a whole new type of rich client / rich server collaborative apps, powered by workflow on SharePoint, and integrated with Outlook.
In the next post, I’ll talk about Access’s new database engine. We’re very excited about this, in large part because it is pretty much exactly the same as our existing database engine. The difference? We own it now and can extend it. Access has always used the “JET” database engine (would you believe that’s an acronym? bonus points to readers who know what it stands for…). JET is owned by the SQL Server team and ships as part of Windows. Access 12 will come with a “privatized” copy of JET that now supports new data types, has improved performance, and better stability. And we can provide a confident future for JET-base applications when SQL Server is slowing development in JET. And it is fully backwards compatible, so existing solutions will run unchanged. Like I say, it’s pretty much exactly the same, except better, and we’re really excited about that.
Joint Engine Technology :)
Hey Erik, great that you started posting, this is a long-awaiting blog for Access devs community!
Nice to see you join the bandwagon. :)
Hi Erik, Thanks for creating this blog. It should be a very helpful took for the development community. I'd like to hear what you can say about how the security model has changed for the new "Jet" engine, if at all. Lynn Trapp
MS Access MVP
Hello Erik! Great to see people will be blogging now. All we have do is have a conversation about collation support in the new engine being brought up to at least Windows 2000 (and maybe even XP/Server 2003).... Feel free to have people contact me if there is interest in adding new collations to narrow the gap? :-)
Hmm, it took 3 days to find out how to post a comment here! It's not at all obvious, when (like me) you have been reading these blogs for some time - and commenting on some of them - but have never created an account or had to log-on. Could you have an anonymous comment button? It's tremendously exciting to hear about the new copy of Jet. I've been wondering how to move my flagship Access/Jet application into the future. This puts a whole new light on things! Looking forward to hearing lots more,
Hi there! I've had this question for some time now, why isn't Access using the SQL Server engine instead of Jet? Microsoft seems to still invest in various flavour of that engines for it's different product that need relational capabilities. Why not focus on making one modular enough that could fit multiple purposes while maintaining a common engine at its core? Will Access 12 use the Reporting Services engine for reports? I have big hopes regarding Office 12 integration with SharePoint v3, I'm very excited to see what's coming on that side. Thanks, Mathieu Isabel
Thanks for the comments (and mails) and I've now got anonymous commenting turned on. Sorry for the inconvenience of having to log on. Lots of comments about the database engine. Probably the best way to address them is through the next post, so please hang tight on that front. Here were a couple of other questions: Highlight a control easily & in continuous forms - This is an interesting point and one that I don't think we've made progress on. Definitely makes sense and something we'll look into. Reporting services for reporting - more on this later, but the short answer is no, we'll be using Access's existing reports engine. There are a number of reasons for this, but the main one is backwards compatibility wiht the 100's of millions of Access databases in the world. I'll do a post later on Access's reporting story and how it fits with the rest of the Microsoft BI stack. Thanks, Erik
Great to see this blog - looking forward to seeing what's new in Access! So many questions, I don't know where to start. I'll just wait and see what topics you post on, then go from there. :)
Whatever cool things you add to Access 12 can you please make it so that forms in the 'user and group permissions' window are listed in alphabetical order and that the window is resizable. With a huge DB it's a real pain having to scroll around this tiny little list box. Thanks! I have a whole list of annoying things that need fixing.
This may be answered in a future post... It sounds like there will be two versions of Jet. One managed by the SQL Server team, and the other by the Access Team. Where does that leave apps that use Jet, but not Access? MSDN shows Jet as being deprecated. Thanks, Ryan
This blog is a really good idea. Thank you for it.
A question for you. I've been developing with Access for about 8 years, yet there is no certification process that will help me show potential customers that I know what I am doing. MOUS has little to do with developer abilities. If I remember correctly, there used to be certification for Access 95. There is a whopping great hole on the certification front. It seems that the powers that be don't really see Access developers as real developers. Or have I missed somthing?
I saw some comments about continous forms- How about that the labels of the field could be linked to the field and dragged from the detail to the header. It is a minor point, but it drives me nuts. Also it makes the drag and drop design easier. I find myself cutting and pasting dozens of controls
Thanks for listening
re:"now supports new data types" Just curious if this will include
an IP Address data type? Thank you for setting up this blog! gary
You stated: "Developers can still program against the Access engine, but since it isn’t part of the system any more, application users will need Access on their machines." Does this mean that the "run only version" will not be available in Access 12?