Recently we were invited to a product interaction session with the Microsoft Access team, it was a wonderful opportunity to discuss what we would love to see in the next version of Access and I’d like to share my responses with you and get your feedback.
If you had $100 to spend on new features, how would you allocate it?
That’s how we were asked to provide feedback, how would you allocate $100 on the new version, and here were my answers:
- $50 on a native SQL Server connection object in Access. No need for DSNs, ODBC, or linking, just a connection object that will make it a breeze to connect with SQL Server. (Similar to .NET’s ability)
- $20 on making Access installer easier and more powerful to work with. The existing installer does not allow installations unless they are accdr, would be nice to have it work with accdb.
- $10 for gestures to control Access on a tablet: 4 finger swipe to move to the next record. One finger swipe to tab to the next field. You get the idea.
- $10 – Native support for table and fields notation. Would love to type tblCustomer. and then get a list of fields in that table. Would make it super easy to build SQL Statements. Speaking of SQL:
- $10 – For the ability to build, maintain and paste SQL from within the code module.
You’re probably wondering: Why don’t I have any money towards Access web apps?
I don’t do web apps for my clients, but if I did I’d love to have the following improvements, (if I could spend more than $100):
- Ask me what screen size to use: The technology can be used on Windows Phone, Tablets or PCs. Would love to have the ability to create specific apps for each or have the system adjust the screen accordingly so I can develop once for all.
What do you want to see on the next version of Access?
If you want table/fields intellisense check out SoftTree SQL Assistant. It’ll work with locally defined Access tables or Queries (which can access linked tables), but not linked Tables themselves. I found this last week (it works for SSMS, Access, NP++, etc).. it’s truly sped up my Access AND SQL development.
It’ll also convert SQL statements to several different languages (VBA being one).
Although I’m glad they are moving to SQL Server the deprecation of pivot tables is a bit of a shock. My wish list is that they keep pivot tables.
Mark, I can understand – it has been useful when you needed it. As mentioned, you could re-implement it as an ActiveX control instead if you want to continue and plan for eventual migration to Excel automation.
My wishes for the next version are (1) to get the calendar ActiveX control back, (2) to get pivot charts back, and (3) to get MS Project integration back. I have more than ten calendars on forms and reports in one of my applications and the deprecation of ActiveX calendars has stopped my development at A2007.
While deprecating things is never easy, I think we have to look at this objectively. COM (which is the base of ActiveX / OLE technology) in general is shrinking. For example, there is no 64-bit replacement for Microsoft ActiveX implementation of common controls and I don’t expect there’ll ever be one. Pivot Chart is based on Microsoft Office Web Components which is not only a COM technology but works on Internet Explorer only (e.g. not HTML standard compliant). Moreover, the Microsoft Office Web Component’s deprecations was already announced few years ago. So far, Access seems to be following along with the general trend.
In our projects, we’ve shied away from ActiveX controls – they simply add more complexity to the installation and are prone to versioning issus. For this reason, we’ve used Access form to provide calendar functionality. You can find several samples on web that provides equivalent functionality.
Pivot*** can be still used in Access 2013 but as an ActiveX control rather than a native Access form so there’s an easier path for those migrating to 2013. However, the fact remains that you have an ActiveX control now and when you compare it with Excel’s Pivot***, it’s quite dated. In recent work we’ve done, we’ve chosen to use Excel automation to build the Pivot*** reports, which is quite beautiful as well.
Best of luck!
My wish is the same as the one we didn’t get in Access 2010: a better SQL editor. Something like the SSMS has, even without all the bells and whistles would be a vast improvement.
Thanks Ben. Option 1 works like a charm, and it is very quick to do, and is what I was looking for. (I should have thought of this myself) I know exactly the context since my code is using Screen.ActiveControl.
However I did try a variation of Option 2 before I asked my question, but I could not set [Event Procedure] properly using an object variable. No need to elaborate here since I now have a good solution, but I look forward to your future blog post on this subject. Thanks again
I would like to see bubbling events to some degree on forms, similar to what Paradox for Windows came out with. I have a form where I placed a Lost Focus event on over 200 textboxes, and all these event procedures are calling the same procedure. This seems like a lot of unnecessary work. It would be much simpler if all these textboxes could be placed on an invisible panel, and I could put my event procedure on this panel, where the events from all these textboxes could be bubbled up to and handled.
I am not recommending the extensive bubbling design that Paradox for Windows developed, with many levels of bubbling which starts and ends with the form, since I think it adds more complexity than is needed, but just one level would do a lot of good. I have wanted this for many years since I do a lot of event programming on controls. I was always surprised that Microsoft found a bubbling event approach to be unnecessary. Do you know if there is a workaround for this?
Access & VBA has supported bubbling events for long time. There are two possible approaches:
1) Instead of using “[Event Procedure]” to handle the event, you can put in “=MyFunction(SomeParameter)” instead. This allow all textboxes to share a common handler without having to write one-line procedure. However, the downside is that you may need to modify the parameters for each textboxes or reference the calling control and you must have good error handling since unhandled errors will be ugly.
2) Alternatively, you can sink events. For example, you could create a VBA.Collection, a Textbox object variable at module level, then at form’s opening, loop the controls to add Set form’s textbox to this module-level Textbox object variable, enable event handling (by setting [Event Procedure] in the appropriate event handler), then add it to the VBA.Collection. As long the VBA.Collection is persisted, all textboxes will share the same Textbox_XXXX event handler defined by the module-level Textbox variable, leaving you with only single procedure, and you have more flexibility in both error handling and detecting the context (e.g. which textbox is calling the current event).
We may cover this subject in a future blog posting but rest assured, this has been available for long time, possibly since Access 2.0, if not earlier.
where is my wishlist post?
Which one was it? I thought I approved all the comments…
I’d like to see integration with Sharepoint &SQL Server so if Sharepoint is installed on a SQL Server, MS Access deployed on the Sharepoint could create relational tables within the SQL Server that hosts Sharepoint – maybe have the Sharepoint installation reserve space for this purpose.
Hi Juan, you say you don’t do web apps while here http://blogs.office.com/b/microsoft-access/archive/2012/09/14/3-awesome-access-2013-web-apps-you-can-build-right-now.aspx you give useful examples of them 😉
By the way, do you have recordings available for http://accessexperts.net/blog/2012/09/14/tomorrow-at-4-pm-so-you-want-to-be-a-computer-consultant-live-on-the-web/
and for http://accessexperts.net/blog/2012/09/06/live-on-september-11th-access-kung-fu-from-microsofts-redmond-campus/
I don’t do them but I do play around with them! No, I don’t have recordings of the sessions, keep an eye out on the blog for future web sessions!