Go to Top

My wish list for the next version of Access

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):

  • Ability to use JavaScript code, not just macros. You don’t want to support VBA on the web? I’m cool with that, but at least let me use SOMETHING to customize the user experience beyond Macros.
  • 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?

About Juan Soto

Juan Soto is a Senior Access Developer at IT Impact Inc. and a Microsoft Access MVP. He specializes in Access with SQL Server databases. His passion for Access has led him to helping a wide range of businesses in helping them establish a secure, stable and efficient environment with SQL Server. He's a frequent speaker at Access user groups nationwide and recently spoke at the Orange County SQL Saturday # 73. If you wish to have Juan speak at your next group meeting you can contact him here.

14 Responses to "My wish list for the next version of Access"

  • Ryan
    June 3, 2013 - 9:18 am Reply

    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).

  • Mark
    October 24, 2012 - 3:30 am Reply

    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.

    • Ben Clothier
      October 24, 2012 - 7:29 pm Reply

      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.

  • David Nealey
    October 23, 2012 - 9:29 pm Reply

    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.

    • Ben Clothier
      October 24, 2012 - 7:28 pm Reply

      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!

  • Steven Franklin
    October 8, 2012 - 11:19 pm Reply

    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.

  • Robert Aaron
    October 8, 2012 - 6:41 am Reply

    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

  • Robert Aaron
    October 8, 2012 - 1:21 am Reply

    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?

    • Ben Clothier
      October 8, 2012 - 4:21 am Reply

      Robert,

      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.

  • ronnie valero
    October 1, 2012 - 6:19 pm Reply

    where is my wishlist post?

    • Juan Soto
      October 2, 2012 - 5:19 am Reply

      Which one was it? I thought I approved all the comments…

  • G
    September 27, 2012 - 4:55 am Reply

    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.

    • Juan Soto
      September 28, 2012 - 3:08 am Reply

      Hi Giorgio:

      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!

      Thanks
      Juan

Leave a Reply

Your email address will not be published. Required fields are marked *

 

Contact Us
  • This field is for validation purposes and should be left unchanged.