The Problem (Q-score 6, ranked #28th of 67 in the Access VBA archive)
The scenario as originally posted in 2012
I have written a database app that imports data from an excel file into a Access database.
I have never had trouble to run the app, to insert records into the database, but as soon as I run the function to import data from the Excel into the Access I get the following warning:
The requested operation requires elevation – by die code:
LAccess := CreateOleObject('Access.Application');
What is causing this and is there a way to get around it
Why community consensus is tight on this one
Across 67 Access VBA entries in the archive, the accepted answer here holds niche answer (below median) status — meaning voters are unusually aligned on the right fix.
The Verified Solution — niche answer (below median) (+8)
31-line Access VBA pattern (copy-ready)
The CreateOleObject delphi function internally calls the CoCreateInstance WinApi method which requires elevation. you have a couple of options to deal with this.
1) Adding a manifest to your app including the requested execution level requireAdministrator.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Your app name goes here"
processorArchitecture="x86"
version="5.1.0.0"
type="win32"/>
<description>your app description goes here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
2) You can launch a secondary process elevated that would do the task or create a COM object that runs elevated, you can find more info in these MSDN entries
When to Use It — vintage (14+ years old, pre-2013)
Ranked #28th in its category — specialized fit
This pattern sits in the 74% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Access VBA archive for a higher-consensus alternative.
What changed between 2012 and 2026
The answer is 14 years old. The Access VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.