A Personal Note to the Access Community
Today is my last day at Microsoft. After many wonderful years, I have accepted Microsoft's Voluntary Retirement Program (VRP) and am beginning a new chapter. It feels a little surreal to write those words. For much of my career, I've had the privilege of working with products, communities, and people I deeply care about. In recent years, that has included serving as Program Manager for Microsoft Access, one of the most passionate, knowledgeable, and dedicated communities in technology. Before I go, there is one message I want to leave you with: Access is alive, well, and continuing to evolve. One of the most common questions I hear is, "Is Access going away?" The answer remains the same as it has always been: No. Access continues to ship with Microsoft 365 and Office, continues to receive engineering investment, continues to receive bug fixes, security updates, accessibility improvements, and yes, new features. In fact, we've released multiple new capabilities recently, including improvements such as enhanced zooming support, larger form and report design capabilities, and new developer-focused functionality, with additional features already in various stages of development and rollout. Over the last few years, I've had the opportunity to work alongside an incredibly talented engineering team that genuinely cares about Access and the customers who depend on it every day. I've seen firsthand the discussions, the prioritization meetings, the customer feedback reviews, the accessibility work, the bug triage sessions, and the long hours spent making sure Access continues to serve businesses, governments, schools, non-profits, and developers around the world. Access remains an important part of Microsoft's productivity ecosystem, and the team remains committed to keeping it relevant, reliable, and useful for years to come. I know many of you closely follow the public roadmap and occasionally worry when it's quiet. What doesn't always make it into public announcements is the steady stream of work happening behind the scenes: security investments, compliance work, accessibility improvements, bug fixes, customer-requested enhancements, and the engineering work required to keep a 30-plus-year-old product healthy in a rapidly changing technology landscape. As for what comes next, I don't yet know who the next Access PM will be or when that transition will occur. What I do know is that Access deserves thoughtful stewardship, active engagement with the community, and a clear understanding of why this product continues to matter. I am hopeful that whoever steps into that role will bring fresh ideas, curiosity, and a commitment to listening to the customers, MVPs, partners, and developers who make this community so special. To our MVPs: thank you for your advocacy, your feedback, and your willingness to tell us what we're doing right and what we're doing wrong. Many of the features we've delivered started as customer requests, conference conversations, forum discussions, and MVP feedback. Your voices matter, and they have made the product better. To the Access developers around the world: thank you for continuing to build solutions that solve real problems. Every time someone says Access is only a relic of the past, I inevitably hear from another organization running a mission-critical application, supporting a small business, managing a research project, tracking inventory, or helping people get work done. The creativity and ingenuity of this community never cease to amaze me. And finally, thank you for letting me be part of your journey. It's been an honor to help tell the story of Access, share new features, write documentation, engage with the community, and occasionally fight to get your favorite feature request prioritized. While I'm retiring from Microsoft, I'll always be rooting for Access and the people who use it. The future of Access belongs to all of you, and I believe that future is bright. Thank you for your support, your passion, and your trust. See you around, Linda Cannon Former Program Manager, Microsoft Access
New to Access
Hello! I am new to MS Access, and currently looking for some advice in working the program. In using Access, I am working with a team that has data in arts and crafts projects that fall under many different categories, which are being exported from Excel. I’ve attached an image of what this data looks like, but I’ve also explained it below. For instance, the data might be sorted into something like 5 fields, those being: project name, square inches, client name, and weight. An example would be: Project 1, 100 sq inches, Client A, 50 lbs Project 2, 200 sq inches, Client B, 100 lbs Project 3, 300 sq inches, Client C, 150 lbs Etc. Then, we’d have a second collection of data that would branch off of the first set. For instance, the data might be sorted into something like 4 fields, being: brand new design, concept design, restoration, or simple cleaning. Finally, a third set of data would branch off of this information, detailing that each of the aforementioned categories have their own data. Such as, brand new design projects use X brand of glue, Y brand of paint, and are always Z color. Whereas, simple cleaning projects might use a totally different brand of glue, paint, and color. Now, my question is, is it possible in MS Access to be presented with all of the data based on what I ask for? Such as, say, I want to view all projects that have used X brand of glue. Am I able to create a database that will pull that up? Or if I wanted to view all brands of paint used ONLY in cleaning projects? Essentially, is it possible to create a database that can show me any combination of information based on what I ask for, creating relationships with one another to search both forwards and backwards with simplicity? If so, what research should I do to approach this, or what other direction do you suggest that I go in if it is not possible? I appreciate the help :)Access begins rollout of Big Forms for Modern Monitors feature
We're excited to announce that support for large-sized forms is now available in Beta for Microsoft Access. This long-requested feature removes the longstanding 22-inch form size limitation and lays the foundation for a more modern, scalable, and accessible form experience. It's one of the most highly requested enhancements from the Access community and a top-voted request on the Access feedback forum. This feature is in Beta now and expected to be in the Current Channel preview by July 21st, 2026. Why we're making this change When Access was originally designed, form dimensions were constrained by underlying technology that effectively limited forms to approximately 22 inches in width or height. As monitor resolutions increased and ultrawide displays became common, that limitation became increasingly restrictive. Developers were forced to design for the lowest common denominator screen size, even when their users had significantly more screen real estate available. The result? Complex business applications often required excessive scrolling, crowded interfaces, or compromises in design. With this Beta release, Access developers can now create forms that take full advantage of today's larger monitors and higher resolutions. What's changing The 22-inch limit is gone. The primary enhancement is simple but powerful: Forms can now exceed the previous 22-inch size limitation. Controls can be placed beyond the historical boundary. Form sections can be designed at much larger dimensions. Developers can create richer and more detailed business applications. For customers building dashboards, operational workspaces, inventory systems, CRM solutions, or other complex applications, this means more content can be displayed simultaneously without forcing users to navigate between multiple forms. Designed for modern workspaces Large monitors have transformed the way people work. Many customers now use: Dual-monitor setups Ultrawide displays High-resolution 4K monitors Vertical monitors for specialized workflows This feature allows Access applications to better leverage those environments. Developers are no longer forced to design around constraints that originated more than 20 years ago. As a result, users can: View more information at once Reduce unnecessary scrolling Create more sophisticated layouts Improve efficiency during data entry and review tasks Accessibility benefits Although the primary audience for this feature is Access developers and users working with larger displays, removing the size limitation also delivers important accessibility benefits. Larger form designs allow more flexibility in presenting information, increasing spacing between controls, displaying larger text, and reducing visual clutter. These improvements can make applications easier to use for customers with low vision and others who benefit from magnified content. We hope you enjoy this improvement and as always, look forward to your comments. (Thank you to MVP Colin Riddington for the thumbnail image.)
Access VBA performance dramatically slowed since June Update
We are running an access based application with a large vba project. One customer with four different instances of this project experience extreme slow down in performance on all instances during the last week. We made no changes. The Microsoft Office Update was applied automatically. We believe the problem happened then. We have tried reverting to several different previous versions of Office but symptoms still remain.Regression in v2606: continuous forms redraw/flicker on main form
As soon as I installed Version 2606 (Build 16.0.20131.20012), all of my continuous subforms on parent forms began constantly redrawing and flickering, making the application almost unusable. Reverting to Version 2605 (Build 16.0.20026.20140) immediately resolved the issue without any changes to the database. I have since disabled automatic updates and am remaining on Version 2605 until this issue is addressed. Has anyone else experienced this problem with Version 2606? Is this a known bug, or has Microsoft acknowledged the regression?
Text Truncation in Access Report Controls
Around May 14, 2026, we began experiencing text truncation on the right side of text box controls in Access (Office 365) reports. Approximately 2–4 characters are cut off whenever font size is below 10pt. All reports in our environment are affected and the problem was not present prior to May 14. We ruled out layout as a contributing factor by verifying page size, margins, report width, control dimensions, padding, and layering were all correctly set. No layout changes resolved the issue. The problem does not occur when font size is set to 10pt or higher, suggesting the update affected font metric calculations for small font sizes. Steps taken without resolution include adjusting all report and control sizing properties, testing multiple default printer configurations including Microsoft Print to PDF and Adobe PDF, and verifying Windows display scaling was set to 100%. If anyone has any solutions, please let me know! Thank you for your time.
Regression in v2605: Subform with overlapping controls breaks timer in unrelated form
I found another issue (sorry) which might be caused by the zoom-related changes in 2605. The following repro example works fine in 2604 (Monthly Enterprise Channel) but breaks in 2605 (Current Channel). Again, this issue is unrelated to zooming itself. Prepare database The repro requires three forms and a few controls. Since those are tedious to get right manually, I wrote some VBA code to do that for us. Execute BuildRepro() in the Immediate Window to create the forms and controls. Option Compare Database Option Explicit Public Sub BuildRepro() CreateFormASubform CreateFormA CreateFormB End Sub Private Sub CreateFormASubform() Dim frm As Form Dim ctl As Control Set frm = CreateForm() Set ctl = CreateControl(frm.Name, acTextBox, acDetail, , , 345, 1140, 1746, 260) ctl.TabStop = False Const textBoxTop = 260 Set ctl = CreateControl(frm.Name, acTextBox, acDetail, , , 56, textBoxTop, 270, 270) ctl.TabStop = False Set ctl = CreateControl(frm.Name, acImage, acDetail, , , 56, 0, 270, 270) Set ctl = CreateControl(frm.Name, acCommandButton, acDetail, , , 60, 795, 5895, 260) SaveAndClose frm, "FormA_Subform" End Sub Private Sub CreateFormA() Dim frm As Form Dim ctl As Control Set frm = CreateForm() Set ctl = CreateControl(frm.Name, acSubform, acDetail, , , 100, 100, 3000, 3000) ctl.SourceObject = "FormA_Subform" SaveAndClose frm, "FormA" End Sub Private Sub CreateFormB() Dim frm As Form Dim ctl As Control Set frm = CreateForm() frm.TimerInterval = 1 Set ctl = CreateControl(frm.Name, acLabel, acDetail, , , 100, 100, 5000, 1000) ctl.Name = "my_label" ctl.Caption = "Waiting for Timer..." frm.HasModule = True frm.Module.InsertText _ "Private Sub Form_Timer()" & vbCrLf & _ " Me.TimerInterval = 0" & vbCrLf & _ " Me.my_label.Caption = ""Done""" & vbCrLf & _ "End Sub" frm.OnTimer = "[Event Procedure]" SaveAndClose frm, "FormB" End Sub Private Sub SaveAndClose(ByVal frm As Form, ByVal newname As String) Dim oldname As String oldname = frm.Name DoCmd.Save acForm, oldname DoCmd.Close acForm, oldname DoCmd.Rename newname, acForm, oldname End Sub Run repro 1. Open FormA. 2. Open FormB (while FormA is still open). Expected result: FormB opens completely, the timer runs and the label reads "Done". Actual result: FormB opens "halfway" (it's visible, but it's tab is still missing, see screenshot below) and the label still shows "Waiting for Timer...". As soon as you right-click anywhere, the form finishes opening and the timer runs, changing the label to "Done". Notes: I tried to make the repro as simple as possible. If you remove one of the controls from FormA_Subform (or enable TabStops), the problem disappears. It might have something to do with overlapping controls: If you change textBoxTop from 260 to 280, so that it no longer overlaps with the image, the problem also disappears. We need the overlapping controls because in our real code the subform is continuous and displays data at different indentation levels (like a treeview).Bug fixes in Microsoft Access - Current Channel Version 2605 (Build 16.0.20026.20118)
Bug Name Issue Fixed Edge Browser Control didn't render PDFs on some machines When the Edge Browser Control was used to display a PDF, on some machines the PDF would not render at all if the registry value "HKEY_CLASSES_ROOT\.pdf\Content Type" was missing. Access now provides the missing content type, so the Edge Browser Control can render the PDF. Export to SharePoint failed for tables with both lookup fields and attachment columns When exporting an Access table to a SharePoint list, if the table contained both a lookup field and an attachment column, the export could fail with an error. The export now handles this combination correctly, so the export completes successfully. Conditional Formatting color picker showed a reduced palette in Version 2604 A regression introduced in Version 2604 caused the Conditional Formatting color picker to display a smaller set of color choices than previous versions. The full legacy color palette has been restored. Some Unicode characters displayed incorrectly in objects exported to Excel When exporting an Access object whose name contained certain extended Unicode characters, the resulting file's sheet name displayed the characters incorrectly. These characters are now preserved correctly during export. Power BI Gateway couldn't refresh semantic models from .accdb files Refreshing a Power BI semantic model that connected to a .accdb file via the on-premises gateway could fail with "Unspecified error". Connection setup has been adjusted so the gateway can successfully refresh the model. Monaco SQL view: Ctrl+Z didn't undo Ctrl+Shift+K line deletion In the new Monaco-based SQL editor, pressing Ctrl+Shift+K to delete the current line removed the line, but a subsequent Ctrl+Z would not restore it. Undo now works correctly for this and similar editing operations. Document tab text didn't scale with Windows text-size setting When the Windows display setting for text size was increased, document tab labels and the record navigation bar continued to render at the standard size, while other Access UI scaled correctly. The document tabs and record navigation bar now honor the system text-size setting. Error when editing a Long Text field after a write conflict When a write conflict occurred on a record containing a Long Text field, subsequent attempts to edit the field could fail with an error. The data path now refreshes the cached field values correctly after a conflict so that further edits succeed. Access terminated unexpectedly when reading Edge Browser Control properties in form design view In form design view, retrieving the ReadyState or LocationUrl property on an Edge Browser Control could cause Access to terminate unexpectedly. Both properties now return safely in design view. "Copy" prefix was prepended instead of appended to copied object names When duplicating a database object, Access named the copy "Copy of Form1" instead of "Form1 - Copy". This made copies of related objects sort apart from their originals in the Navigation Pane. Copy-of names now append the suffix, so related objects stay together when sorted alphabetically.
