For the third straight year, Access DevCon Vienna was a virtual event.
Karl Donaubauer organized the event with substantial assistance from Philipp Stiefel and Peter Doering. Once again, the three-man crew did a phenomenal job of herding the attendees and presenters. The scheduled presentations all ran on time. The only sessions that ran long were the end-of-day feedback sessions, but that just meant that there was time to answer nearly every question from the audience.
Pulling off an event like this is no small task, but the three hosts made it look easy.
The following people presented on Day 1:
- Maria Barnes: Dataverse Connector
- Michael Aldridge & Joe Jimenez: Access Roadmap
- Kevin Bell: Deployment Service
- Chris Arnold: Access Studio
- Mike Wolfe: Understanding COM
- Colin Riddington: Annotating Google Maps
Once the recordings are available to attendees, I will provide more comprehensive reviews of each session. For now, I'll just write a few words about each one from memory.
Maria Barnes gave a comprehensive update on the Dataverse Connector.
It was a great opportunity to hear from a non-Microsoft person who's also an expert on this emerging technology. She presented some non-scientific performance benchmark data.
Two things stood out to me on the benchmark data she presented:
- Moving to the last record of a large recordset is extremely slow
- Performing an update on a large number of rows is also extremely slow
This leads me to believe that tables linked with the Dataverse connector do not behave like typical ODBC-linked tables. For example, moving to the last record in a SQL Server-linked table is very fast, because of how Access fetches the records behind the scenes.
It would appear that Dataverse-linked tables perform all operations row-by-agonizing-row (RBAR). To make matters worse, pass-through queries are not available to work around these performance problems (Dataverse data is actually stored on Azure SQL–i.e., SQL Server cloud–databases).
Unless that situation changes in the future, I don't see Dataverse being useful for anyone other than Microsoft's real target audience. Maria hit the nail on the head when she identified that target audience in her presentation:
Dataverse Target Audience: Corporate and IT execs to provide more governance of the data
In other words, this feature was created mainly for CISO's and IT directors at large, highly regulated enterprises who have been developing ulcers at the thought of having dozens or even hundreds of Access .mdb and .accdb data files lurking about on network shares with who knows what kind of security.
The Access Dataverse connector is the perfect tool to get .mdb/.accdb data moved off-premises and into the cloud.
If you are comfortable working with SQL Server, you are almost certainly going to be better off migrating to Azure SQL than to Dataverse.
Michael Aldridge, Principal Program Manager for Microsoft Access, and Joe Jimenez, Software Engineer on the Access development team, gave an update on the current Access Roadmap.
To start, Michael apologized for all the release dates that have been missed in the past. Microsoft has a fix for that situation. "Adding resources to the Access team?" you ask. No, unfortunately not. The fix, it seems, is to simply not show a feature on the roadmap until Microsoft has 90% confidence that they can meet their published release dates.
As an alternative, Microsoft will publish a list of current development priorities on their official blog–a completely different area of the website from the roadmap.
Here is the current roadmap (note the Dataverse Connector and Graph Data Connector GA dates of March 2022 have already been missed):
Here is the future roadmap:
In other words, the public roadmap is going from six listed features to one. But don't worry, says Microsoft, nobody will think this means Access is dying.
Oh, and in case you were curious, here are the current counts of in-development, rolling-out, and launched features for the Office apps:
- Access: 8 (6 in development; 0 rolling out; 2 launched)
- Excel: 27 (11 in development; 2 rolling out; 14 launched)
- Outlook: 114 (40 in development; 8 rolling out; 66 launched)
- PowerPoint: 10 (4 in development; 1 rolling out; 5 launched)
- Word: 15 (3 in development; 3 rolling out; 9 launched)
Modern Browser Control
After Michael Aldridge presented the roadmap, Joe Jimenez talked about the modern browser control.
The bottom line is that the project has been delayed due to a fundamental change in architectural design. The Access team is leveraging the work of the greater Office team. Instead of developing an Access browser control based directly on the WebView2 control, the new Access browser control will be based on the Office Solution Framework (OSF) control.
OSF is a wrapper of the WebView2 control. The upside is that upgrades to the OSF control will flow down to the Access control. In other words, when WebView3 comes out (or whatever the next thing is), it will be up to the Office team to implement it.
That is a good thing for us Access developers, as I'm fairly certain the Office team is better resourced than the Access team.
The downside is that the Access team gives up some control over the browser control. They can no longer write code directly against the WebView2 API. Instead, they have to use the OSF APIs. If they want to use some feature of WebView2 that OSF does not expose, the Access team has to lobby the Office team to provide access to the feature.
Here's a graphical representation of the situation. The straight lines represent APIs. Notice that not every line from WebView2 reaches the Access team.
I'm closing in on a thousand words now, so I will cover the remaining presentations in one or more future articles.
UPDATE [2022-05-03]: Updated cover photo.